Pause works as intended when currently no backup is running. A scheduled backup will not start.
If a backup already has started and is in its initial phase of counting the files, pressing pause does nothing. Duplicati will continue counting all files in the backup set until it reaches the total number of “Files to Go”. The actual backup then does indeed pause.
I would expect Duplicati to fully pause all processes when Pause is selected. In particular the file counting process is very hard drive intensive and might interfere with something else I am trying to accomplish.
That does seem like the kind of thing that should be doable. If we can update the progress bar then we should be able to detect a pause request.
However, it may be that the file scan is very OS dependent in that once Duplicati asks the OS for a file list it may no longer have much control over when it finishes.
It may also be that the OS can’t pause a scan in which case it’s either finish or abort.
Does --use-background-io-priority help with the disk use issue?
I have the same problem. I hit pause and the upload continues. I would expect if to freeze until I resume.
To pause I have to stop the whole process and start it back again, which will have to process the whole thing again (check which file has been uploaded, etc).
I’ve noticed the issue that lucasarruda is mentioning after upgrading from 2.0.3.5_canary_2018-04-13 to 2.0.4.12_canary_2019-01-16, so it must’ve been introduced somewhere between 2.0.3.6 and 2.0.4.12, inclusive.
The issue is that pausing an already-started operation does not really pause until its in the last stages, somewhere when checking for deletions or verifying remote data…
I have a feeling (call it a hunch) that this is somehow related to multi-threaded processing. Some thread(s) are not checking for the pause signal and just go on and on…
There’s another thread on this which gets more into the details, and my hunch is the same as yours. Pause is not Pausing discusses. I didn’t study closely to see where all the old checks migrated to (or disappeared) during the big rewrite for concurrency that 2.0.3.6 did. I think I saw an older issue about problems created from pause or stop, so there’s a chance that omission is avoiding some problems. Someday, though, it would be very nice if the functions worked again (assuming things don’t break)…
