Having zero copies of source files (i.e. deleting first) is less safe than having one while aiming to get two. Testing restores periodically can add confidence that it will work, but why push your luck? See below too.
Restore performance may also get dramatically worse after deleting source because Duplicati’s restore favors restoring file blocks from source files where possible, i.e. when the block to restore is unchanged. Specifying –no-local-blocks turns off this optimization, so is a good idea for a true test of remote restore.
The above file contains logging. Logging at verbose log level can show which way you restored, such as:
2018-12-16 21:00:02 -05 - [Verbose-Duplicati.Library.Main.Operation.RestoreHandler-FilePatchedWithLocal]: Target file is patched with some local data: C:\restore here too\short.txt
2018-12-16 21:00:05 -05 - [Verbose-Duplicati.Library.Main.Operation.RestoreHandler-PatchingMetadata]: Patching metadata with remote data: C:\restore here too\short.txt
For a dual fast/slow backup situation, the other topic mentioned xcopy /d as a possible way to update an older backup with newer files, but adding the further wish for “updating” with newer deletes limits options.
Programs exist for reconciling differences between trees of files. For example, WinMerge can show you newer deletions because the files will be in the old backup but not the new one. You can then delete files from the restored old backup. It can show file differences. You can propagate them from the new restore.
Ultimately the goal might be exactly what’s in the new backup, using the old one temporarily because it’s faster to restore. The simple solution might be to just use that as a read-only reference to be replaced by the new after the new is done. Old restore getting source files will help new restore get its source blocks.
You have a harder merge problem if you start actually changing files in the faster restore of older backup.
If you absolutely have to automate this instead of going into WinMerge, setting up the “View”, then acting, there’s a chance that rclone sync can do this, but it depends on whether this option overrules strict sync:
-u, --update Skip files that are newer on the destination.
These posts from rclone Issues give me hope that it can handle minor messiness, but I haven’t tested it.
Allow to avoid synchronization of files that changed in the target #1328
Model sync deletion after rsync #384