Thanks for the response, just to provide an update I created a backup set to test this and long story short it seems to work properly the way I hoped it would work. I’ve included some information on my testing process below, and I may have also discovered a bug in the restore functionality (detailed below also).
To begin testing, after creating a new backup job I stopped the backup allowing it to finish the current upload (confirmed also that when it stopped, it had not uploaded all files yet), I then changed the destination to another local location.
When I first tried to start the job again after the destination change, I got the missing files error as you mentioned:
Found 19 files that are missing from the remote storage, please run repair
Attempting to run a repair copies across the
dindex.zip.aes files which existed in the original destination to the blank destination (which would have caused a filename merge conflict later if I tried to merge both destination’s files), however the job still does not run unless I add
From here, I decided to start my test fresh without running the repair, as having run the repair may cause more issues down the track when I merge the files. I deleted the backup job and backup files, and started fresh.
This time, without running the repair and with
--no-backend-verification the backup started to resume in the new destination where it left off in the original destination.
The job uploaded the new dblock, dindex and dlist files (the filenames in this instance did not conflict at all with the previous destination).
Just to add, after the backup finished successfully in the new destination, and before merging the two destinations (and before changing the backup destination back to the original destination) I tried to run some test restores to prove that my files weren’t being uploaded twice. Originally I had an issue where a file that was backed up in the initial run to my first destination could still be restored even after I changed the destination to my second location. (The blocks for this file were only in the original location!)
I must have discovered a bug, as the original file path (source of the backup) still existed so I caught Duplicati copying the original source file to the restore location, instead of reading from the backup files. This was proven by renaming my source directory, which then made the restore error out due to cannot find the block file - and this was my expected outcome as it proves to me that the files processed when I started the job for the very first time were not backed up again after I changed destinations.
I could merge the two destinations without any conflicts. After changing the destination back to the original location everything seemed to run fine, restores worked from all restore points both on the original destination and the second destination. The restored files also did not have any issues, one of them was an installer which performs its own integrity check and that passed with no issues.