I have two Ubuntu machines, A and B. Both running the same OS release and the same duplicati release. Both are on the same LAN, talk to the same router which is the gateway, and both use the separate directories on the same backend.
Until very recently backups worth fine on both machines. Machine A still works fine. On machine B I get an infinite hang at either Verifying Backup Data or Waiting for the Upload to finish. B seems to be backing up files, but then hangs on the Waiting for Upload. I have verbose logging on, and at the Waiting for Upload I see a few puts and then nothing.
I’m on 2.0.6.3_beta_2021-06-17 and see same thing on my Ubuntu 20.04.5 (Focal Fossa) server: “Waiting for upload to finish…,” particularly when backup is stopped from GUI to stop after current file. Storage is OneDrive v2 and remote volume size configured is 250MB. Internet connection (cable DOCSIS) has upload speed of about 11.3Mbps, and download over 300Mbps.
if Mbps means bit per second, one block will need about 3 minutes to upload. That may be too long. I’d set the dblock size back to its default value of 50 MB in your place.
More on diagnosis than prevention (where you were given one suggestion which possibly helps),
is probably the end sequence, although for some reason some steps don’t seem to show on status.
is possibly the range of code where it sits (unknown why). You can see the phase changes below in
which seemingly you got, because the status line shows it, however it didn’t then proceed further into
I don’t know all the code here, but another suggestion would be to look at About → System info at Server State Properties and especially lastPgEvent which is too wide and might need to be obtained by selecting and copying the full screen into some editor where you can examine the line.
IIRC there are a couple of counts, where one is what’s supposed to be uploaded, and other is what actually has been uploaded so far. The first advances with need. The second is supposed to follow.
One problem with OneDrive is that unless you increase http-operation-timeout, large transfer could experience failures from Microsoft’s 100 second default timeout, although it’s usually pretty obvious.
I suppose you can also look on OneDrive to see what the latest files are. Normal ending needs a dlist. Before that there are dblock files and dindex files. These uploads come from your user Temp folder, so looking around for leftover files of about the right date whose names start with dup- may be an option.
You can also keep a log-file. log-file-log-level=information will log the basics such as when the uploads begin and end. Increased levels are possible, with verbose somewhat more. profiling level is huge.
How you recover from this (which isn’t described) might be another opportunity to get clues by analysis.
Update: The hang seems to have been caused by slow Linux (Ubuntu 20.04.5) smbclient performance for Duplicati to access source filesystem(s), which are hosted via Linux CIFS (Samba) mounts to shared folders on Windows host(s). I’ve addressed the source of the this performance and the Duplicati backup stop feature “hang,” which seems now to actually been a very long delay.