Copy - all snapshot revisions exist at the destination


#1

I’ve got two cloud storage locations. The same local storage is backed up to both (-bit-identical used). Both have had the same number of backups run so they have the same number of revisions, 10 each.

Wasabi 's revision 10 is more recent than Google Drive’s revision 10 so I tried copying the latest Wasabi revision to Google Drive as in theory it should be quicker than running a new backup job.

I get the response all snapshot revisions exist at the destination.

I assume this is simply because Google Drive already has a revision 10?
Or is duplicacy checking that both revision 10’s are identical before telling me it already exists (it is possible that both are already the same since no files may have changed)?

Is there any way to make duplicacy copy the latest revision even if a revision with the same number already exists?


#2

All 10 revisions exist in both locations. From :d:'s point of view there’s nothing to copy around.

I don’t think you can just overwrite revisions.

I imagine you could create a new snapshot copy-of-wasabi on gdrive, and do the copy like that. in that way you’re 100% sure you have the same chunks.

Another thing you can do is delete snapshot 10 by hand, then do the copy.

A third (the good thing in general) to do is make a backup (either to gdrive or wasabi) and then copy that snapshot to the other storage, instead of doing 2 separate backups.


#3

Thanks, I was attempting to do the third option at the time.

I had set up the two cloud locations and had been running backups of the same data to both. They both had 10 backups. I decided I wanted to start copying to one instead of backing up to both. Since Wasabi had the latest backup I wanted to copy it to GDrive. When I tried copying I got the ‘error’ about the revision already existing.

Thanks for clarifying that duplicacy just checks to see if there is already a destination revision of the same number.

Feel like this could be quite a common occurrence where someone tries to copy to a destination which has already had a bunch of backups - thus resulting in clashing revision numbers. I would have thought that it would just copy anyway and increment the destination revision number. Now I know.

Just to confirm that I properly understand how copying works…

  • I set up multiple cloud locations and have been backing up the same data to each one.
  • I want to switch to only backing up to one of them, Wasabi, then copying that revision to the rest. I’m only copying the latest revision since I have different pruning rules for the cloud providers.
  • If I copy from Wasabi, I assume it will only copy over the chunks that are not already in the other locations? And the other locations will already have a lot of the same chunks since we used -bit-identical?