Backup fails... Failed to decrypt the chunk - storage doesn't seem to be encrypted

Support
#1

Hello - I have a backup that has worked successfully for some time, but recently it has started failing with this message being the final one in the log:

I’ve included the end of the log here to show chunks that are copied, chunks that are skipped, and then chunks that fail with an encryption message.

This is a copy from local to backblaze, where the storage is encrypted.

I’ve recently had some hard drive issues on this computer (fortunately just on the backup partition) so it’s possible something has gotten corrupted. Could someone provide a pointer please as to how I can troubleshoot this?

Thank you!

Beginning of Log:
Running copy command from C:\Users\jason.duplicacy-web\repositories/localhost/all
Options: [-log copy -from LocalMain-DrivePool -to b2]
2020-04-13 10:05:57.133 INFO STORAGE_SET Source storage set to G:/duplicacy/duplicacy
2020-04-13 10:05:57.201 INFO STORAGE_SET Destination storage set to b2://
2020-04-13 10:05:57.631 INFO BACKBLAZE_URL download URL is:

Tail of log follows before it fails.

2020-04-13 10:07:48.314 INFO SNAPSHOT_COPY Chunk 551c42cde8fd3705821b0deda4613c894fb40bc7f6323312f6058218fcda4c6e (31/199572) copied to the destination
2020-04-13 10:07:48.314 INFO SNAPSHOT_COPY Chunk 99e9b39051cd5e7d3a4ca942e7043616eb04d251b081ab309427a133c0499667 (43/199572) skipped at the destination
2020-04-13 10:07:48.314 INFO SNAPSHOT_COPY Chunk 257b8f9ff9bddcbd95f04d5a97baa1aba028397b19be792362b593dd82b02360 (44/199572) skipped at the destination
2020-04-13 10:07:48.314 INFO SNAPSHOT_COPY Chunk 2165b5a53756119e7ea67461e9e6ff497e12afb0762ab18733780a98b8905108 (45/199572) skipped at the destination
2020-04-13 10:07:48.314 INFO SNAPSHOT_COPY Chunk 4c64b5171e5df013a666ab97618e83f74beb7a1da3365e1fcae72d8660dab2e5 (46/199572) skipped at the destination
2020-04-13 10:07:48.314 INFO SNAPSHOT_COPY Chunk d48fe677eb69aa9ce731a7fde56acea09e1f86680211b9f89cfdc1c655ff28db (47/199572) skipped at the destination
2020-04-13 10:07:50.439 INFO SNAPSHOT_COPY Chunk 988a299ad7e6e6c3855d1d81cc50d9cdd64fcf897838e273912ae557e4639c0c (39/199572) copied to the destination
> 2020-04-13 10:07:50.540 WARN DOWNLOAD_RETRY Failed to decrypt the chunk 6df57eade975c6ad930d9afe10677f10af56ef335d643482c32503788366e614: The storage doesn’t seem to be encrypted; retrying
> 2020-04-13 10:07:50.540 WARN DOWNLOAD_RETRY Failed to decrypt the chunk 6df57eade975c6ad930d9afe10677f10af56ef335d643482c32503788366e614: The storage doesn’t seem to be encrypted; retrying

Backblaze B2 timing out on all computers
#2

Encrypted chunks always start with duplicacy. If this header is damaged that Duplicacy would think the chunk is not encrypted and hence the error message.

#3

Thanks for the fast answer. Can you tell me what I need to do to fix it please ? Thank you.

#4

Your first step should be to try to verify the integrity of your local storage with the check command. Perhaps it will identify which chunks belonging to which snapshots are corrupted, if any.

From there you can work out how to proceed. Maybe copying snapshots back from b2? Or manually deleting bad snapshots (which will likely only include the last few). Either way, make sure your local storage hardware is in good nick.

Resist the temptation to ‘start from scratch’, because unless your storage is completely toasted (in particular; the config file is corrupted, which it doesn’t appear to be), it’s very likely fixable.

#5

I would copy the latest revision (from local to backblaze) first. This revision should be treated differently because if there are corrupted/missing chunks it is more likely to recover them. If the copy completes without an error that would be good, but if there are any corrupted chunks, remove them first, and then create a new backup with a different backup/repository id. The new initial backup may (or may not) recover all corrupted chunks.

Then copy other revisions, one at a time. If the copy fails then you’ll have to delete the revision with the prune command.

Finally, run a check on all revisions that have been copied to backblaze before. Delete any corrupted chunks encountered, and then run a copy from backblaze to lcoal.

1 Like
#6

Thank you for the guidance. I’m making progress using these steps. I’ve now identified the specific snapshot ID that has the problem with the chunks. I’ve tried just copying that snapshot again but it fails with the chunk that appears to not be encrypted. (and once I create another revision of the backup, the chunk giving the error changes). Can you please tell me how I remove only the specific chunks that are providing the error please? I know how to prune out specific revisions of a snapshot ID, but not specific chunks. Once I’ve done that, I’ll follow your advice to create a new backup with a new ID. Thanks again!

#7

You just need to access the chunks folder in the storage. Remembering that the first two characters of the name of the chunks are actually the folder where it is.

For example, for chunk

6df57eade975c6ad930d9afe10677f10af56ef335d643482c32503788366e614

you’ll find at:

6d / f57eade975c6ad930d9afe10677f10af56ef335d643482c32503788366e614

#8

Thanks, that was too obvious I guess :slight_smile:.

I deleted the chunk in question, ran the copy again, and then a new chunk appeared with the same problem. I did this 5-6 times and it seemed an endless game of ‘whack-a-mole,’ so I created a new backup with a different snapshot ID as suggested.

Also from @gchen 's last instruction, I tried copying the revisions one at a time from the original snapshot ID and deleting them one at a time until I get back to a revision that works to copy. I ended up having to go back a couple of weeks but eventually found whatever the culprit must have been, removed that snapshot, ran a full backup & copy today, and it completed. Thank you both for the quick support. It’s awesome to see the forum so actively supported for help.

1 Like