Stop now doesn't stop immediately

“You are currently running Duplicati - 2.0.6.1_beta_2021-05-03”

I’m running a Duplicati backup and at some point I want to play a game online or I want to shutdown my computer. So I click the ‘stop’ icon in the GUI and choose ‘stop now’.

However, the status indicator will change to ‘Stopping after the current file’, even though I choose ‘stop now’. Furthermore, there is still network activity.

How do I really stop a backup immediately?

I think that’s just because there’s one message for both. I’m not a web developer, but I think it’s here:

I mentioned this in a comment on an issue, but feel free to file a new Issue to get it in the queue.
The easy fix would be to make the message generic to cover both types. Customizing is harder.
I suppose if there were two, “Stop now” one could state the message about file uploading again.

Stop now results in “Detected non-empty blocksets with no associated blocks!” #4037

Stop now would announce Stop after current file, which is kind of the wrong stop type

Presumably file uploads mentioned in below.

image

Short of killing the process, I don’t think you can. Hard stops may leave messes. Backups dislike those.

Duplicati does try to recover from unexpected hard interruptions (e.g. power failure), but recovery won’t happen until next backup run. At that next time, it uploads a synthetic file list covering what it got that far.
After that, backup runs, avoiding second uploads of source file blocks that it finds are already uploaded.

I wouldn’t recommend killing Duplicati on purpose though, as I don’t think the recovery from it is perfect.
You can maybe make “Stop now” (misleading name, but what to say – and then what to call the other?) slightly faster by making asynchronous-upload-limit smaller (e.g. 1), but short queue may slow backups.
I haven’t timed all of the speedups-of-stop/slowdowns-of-backup I offer here, but you could time them…

Setting a small Remote volume size will reduce the queued data, but may be slow for a very big backup.

I’m not sure how fast your upload is, but on my rather slow link, I can probably upload a 50 MB dblock in about 90 seconds. This gets slow when uploads run in parallel, but that speed-booster can be disabled:

  --asynchronous-concurrent-upload-limit (Integer): The number of concurrent
    uploads allowed
    When performing asynchronous uploads, the maximum number of concurrent
    uploads allowed. Set to zero to disable the limit.
    * default value: 4

Thanks, that explains a lot!

I think the message “You can stop the backup after any file uploads currently in progress have finished” was misleading me. It should be “You can stop the backup now, but it will continue with any file uploads currently in progress”.

It’s also not clear to me anymore what “current file” is, or what actually the difference is between “Stop after current file” and “Stop now”.

I understand it’s difficult to be robust against a hard stop, but on the other hand there are many failure modes that could lead to a hard stop, right? Even simply disconnecting internet or a disconnect iniatied by the cloud storage has the same effect. I understand there will be waste and can accept that some files are uploaded that were already uploaded.

Another option would be that I set my upload speed to 10kB/sec or something ridiculously slow. If that is in effect quick enough it’ll be good enough to play a online game.

I have my dblocks at 250MB and it should take ~300 sec. I’ll try to see how long it takes between “Stop now” and observing no more network activity.

The forum can’t track issues. If you wish to suggest this reasonable change, please use a GitHub Issue.which will get it in the issue queue for the developers to potentially implement at some point.

When a backup runs, there’s a Current file path below the usual backup statistics on the home page.
There’s also a Progress bar that advances to show how much of current file has been processed so far.

That is different. number-of-retries and retry-delay attempt retry failed operations. If not possible, an error occurs, which typically winds up well because program logic handles it. Sudden death is more traumatic.

That will make stops even slower, and risks timeouts. They can sometimes can be fixed by option values.
If you want to set up a minimum-impact approach, also see thread-priority and use-background-io-priority,

1 Like