Duplicati uses SQLite to provide transactional storage, meaning it will either be written completely or not at all. It keeps track of all remote files and will generally be able handle everything nicely.
It marks all files “uploading” when they are in-progress, “uploaded” when they are reported as completed, and “verified” when they have been seen in a file listing.
If you interrupt it, the next run will look at all “uploading” files and check if they have the full length as it expects, and if so it will promote them to “uploaded”. If not, it will delete them for you.
It does two things.
- It uploads a synthetic filelist, which is “the last filelist + whatever managed to get uploaded in the interrupted backup”
- Performs the backup as usual
Since all backups re-use the uploaded data, (2) is the same as “resume”.
It should fix things by itself. As @JonMikelV mentions, it can happen that this is not the case, but we should try to fix that.
Generally, don’t set --auto-cleanup. It will run the “repair” command automatically if something is wrong with the remote destination. The reason why this is not done automatically is that it can destroy data.
Duplicati keeps a list of expected remote files, and if the remote files are missing or there are extra files, somethings strange has happened and Duplicati does not know what to do, and asks you to “repair”. You should check the error message and see if the error has an explanation before you repair.
The “repair” scenario is intended as a way to recover from something that fails, but it is not meant as an everyday fix. If the automatic handling does not work, you should fix the problem (change storage provider, investigate etc) instead of trying --auto-cleanup.
If you change the destination or similar, Duplicati might see files that it thinks are “extra” and just delete them. You can catch that with the error message, but --auto-cleanup will just remove the files.