Fedora 31 workstation, Duplicati - 18.104.22.168_canary_2019-11-05
When nearing the end of the backup, the file size remaining to be backed up becomes a negative number. I am attempting to upload a screenshot here.
When the backup first starts, Duplicati scans the filesystem to find files that should be backed up and it also notes the total size of all those files.
If some files grow larger after they are scanned at the start of the backup - but before Duplicati has backed them up - then it can throw off this ‘bytes to go’ calculation.
It is superficial and can be ignored. The UI should probably be adjusted to hide the ‘xx bytes’ portion if it goes negative.
A fix was made a few months ago for another situation where this number could be negative: files were temporarily counted twice against the total bytes processed. But your version has that fix so this is a different issue - probably file growth during backup.
Just adding that I think I ran into the same bug. While the backup was occurring, I added some zip files. I then ended up with this and the backup got “stuck”. I had to restart the Duplicati service entirely.
How long does your backup job run? As I mentioned above, one cause of this issue is when the files change between the time the job starts and the time Duplicati actually gets around to backing up those files. But your numbers are really large. Seems quite odd especially if your backups complete in a short timeframe.
The negative values show up immediately when the job starts, so doubtful it has to do with a file changing between the scan and the actual backup. Also not sure what you consider a “short timeframe”. Most of the jobs I have are examining and backing up 10s if not 100s of GB, depending on activity. The shortest backups I have take a few minutes, the longest nearly an hour.
To my programmer nose, this smells like bad signed int → long, long → int conversion.
Try this… open two tabs to the Duplicati Web UI. On the first tab navigate to About → Show Log → Live → and set the dropdown to Verbose. On the second tab, start your backup job. Quickly go back to the first tab and watch for any errors while the filesystem is enumerated.
Yeah we don’t need a full log… I was just hoping some sort of problem would be visible that you could screen capture. Maybe try the test with Live Log set to “Warning”, it should help reduce the output.
Ok, I like your idea of testing with a small amount of data. I think you might need to use the various log-file options to save logs to a file. Try setting the log level to Verbose and run your test again.
For files, remaining is 787 - 225 = 562. For size, remaining is 569002300 - 25079669 = 543922631.
That’s 518.73 MiB (I guess the status bar MB is really MiB). From message search, I think the code is
The web UI gets it from the server, so it’s also possible to capture packets or maybe use browser tools.
Edge F12 Developer Tools caught a series of progressstate. An example of what the server returned: