Duplicacy keeps stalling

Support
,
#21

I think this is a sign of an undetected error when creating the initial backup to Wasabi with duplicacy. This is why:

  1. I backed up directly to Wasabi.
  2. I created a new local storage using duplicacy add -copy.
  3. I copied the config file and the snapshot files from Wasabi to the local storage thus created, so the same encryption keys would be used.
  4. I backed up directly into my new local storage. Since it used the same parameters including the same encryption keys, it created the very same chunks.
  5. Against the local storage, I ran duplicacy check and (manually) copied missing chunks from Wasabi to the local storage until duplicacy check completed successfully.
  6. Against the local storage, I ran duplicacy check with the -files option. It took days but it completed successfully with no issues. I am therefore absolutely confident that the local storage is OK.
  7. As above … I ran duplicacy restore to restore from Wasabi into a new repository. It failed.
  8. I downloaded the failing chunk from Wasabi and compared it to the chunk from the local storage. They are different. They are exactly the same size, but their contents are completely different.
  9. I uploaded the chunk from the local storage into Wasabi.
  10. I am now running the same restore that failed. It’s still going but it is past the chunk that it was getting stuck on.

The chunk on Wasabi was wrong. This could only have happened during the backup. Or after, I guess, if you think it’s credible that bit rot did this on the Wasabi end.

It could be a problem with duplicacy or a library it depends on, or a problem with Wasabi.

The working chunk starts with “duplicacy\x00”. The corrupt chunk does not. Adjacent chunks on Wasabi also start with “duplicacy\x00”. So far this is the only one that doesn’t.

#22

That chunk doesn’t have a valid encryption header. Can you download it from wasabi.com and check the first 10 bytes of the file? Do you have a local copy of that chunk (if you copied from local storage to wasabi)?

#23

Yes, I have both chunks. It’s how I know they were different. The bad chunk starts with

46 ac 59 b1 59 f9 17 83 08 b8

Is there a way to tell if it’s a valid but unencrypted chunk? It’s definitely not encrypted because there are large swaths of repeating sequences which you shouldn’t see in ciphertext.