Size on one of my storages drops to zero every 7 days

Support
#1

I have 10 backups configured and 5 storages assigned. All backups use the same schedule. Backup daily, daily check and prune weekly. The prune setting is “-keep 0:60 -keep 7:14 -keep 1:7 -a”.

Everything seems to be working fine except for one storage that has 3 backups going onto it. Every 7 days, it seems to drop to zero size. See this image:
Imgur
The odd thing is that while ‘All’ goes to zero, the size of each backup does not fluctuate.

Can you help me figure out what is going on? Why is it deleting all the remote data on that storage once a week?

#2

It’s not deleting data - the stats are not crucial to the backup data and kept local. But are you using the latest version of the Web Edition - v1.4.1? I believe something to do with the stats was recently fixed…

#3

Yes, this bug should be fixed in 1.4.1. The cause was that the check job didn’t run on that day but a prune job did so check stats were all zeros.

#4

Thank you for the clarification! Appreciate it.

Ah yes. I’m running the saspus docker on Unraid and it looks like the version is 1.3.0.

Hope I get the update soon!

#5

I don’t think this is accurate.

saspus/duplicacy-web:latest is currently 1.4.1.

saspus/duplicacy-web:mini also defaults to 1.4.1, but you can change environment variable there to any other version and restart the container to switch to that version, without the need to download new image

https://hub.docker.com/r/saspus/duplicacy-web/tags

#6

Hi, I think my auto update on your docker was disabled. A precaution to make sure Unraid wouldn’t kill the docker while it was in the midst of a backup. I’ll update now. Thanks for taking the time to respond (and for making the docker!) :slight_smile:

#7

This is the correct approach though – nothing should be allowed to autoupdate on someone else’s schedule. because new versions not only bring bug fixes – but also new bugs.

This is a very good point. The container when it is being stopped should send TERM signal to duplicacy web which should shutdown any running cli instances gracefully. That was the intent; I’ll verify this is the case. Thank you.

#8

Yep, that’s the case. The container can be safely stopped any time – duplicacy_web receives TERM on stop.

The safety of this relies on the duplicacy_web sending TERM signal to duplciacy CLI, and duplciacy CLI handing that TERM signal gracefully (not leaving half-uploaded files on the destination specifically). But that’s beyond my control :slight_smile:

#9

The CLI can be terminated any time and it shouldn’t leave any half-uploaded files on the cloud storage server, if the server behaves properly, because the content length is always set and the server should never store an incomplete chunk file shorter than the content length. OneDrive for Business is an exception but we’ve fixed that in the latest CLI release by using a different upload API.

For non-cloud storages like sftp and local disk, the CLI uploads to a temporary file first and then rename the temporary file once the upload completes. Aborting should cause any partial upload.

1 Like