"cipher: message authentication failed" on specific chunk (web edition)

Please describe what you are doing to trigger the bug:
Any check, prune, copy, or attempt to list revisions that references this snapshot. This is a hard error that is completely repeatable. New backups run fine.

Please describe what you expect to happen (but doesn’t):
No error

Please describe what actually happens (the wrong behaviour):
example from prune:
Running check command from C:\ProgramData/.duplicacy-web/repositories/localhost/all
Options: [-log check -storage onet-server-01 -a -tabular]
2020-03-23 22:17:12.509 INFO STORAGE_SET Storage set to sftp://onet_admin@onet-server-01///tmp/mnt/backup/duplicacy
2020-03-23 22:17:14.105 INFO SNAPSHOT_CHECK Listing all chunks
2020-03-23 22:18:07.045 ERROR DOWNLOAD_DECRYPT Failed to decrypt the file snapshots/Professional/4847: cipher: message authentication failed
Failed to decrypt the file snapshots/Professional/4847: cipher: message authentication failed

Comments:

  • what might cause this?
  • how do I recover?
  • how do I prevent in future?

Background:

  • scheduler runs backups from laptop to NAS via sftp every 15 minutes
  • daily check and prune of NAS and copy on cloud (B2), then copy of local to cloud

Thanks!
Jeff

That error means the snapshot file (snapshots/Professional/4847 on the storage) is corrupt. Check the file to see if there is anything obviously wrong (0 size, repeats of same random bytes, etc).

If you don’t need to keep that revision (4847), the fix is simple: delete that file from the storage, and then run duplicacy prune -exhaustive -exclusive to clean up chunks only referenced by this revision (while no backups are running).

If you want to recover that revision, this may work: first, you should be able to find a cached, unencrypted copy under C:\ProgramData/.duplicacy-web/repositories/localhost/n/.duplicacy/cache, where n is the index of the backup. Copy the file to C:\ProgramData/.duplicacy-web/repositories/localhost/all/.duplicacy/cache/onet-server-01/snapshots/Professional/. When you run check or other command it should not complain about the error.

Thanks. I looked at the snapshot file and didn’t see an obvious problem (it was non-zero length and a byte dump showed no obvious patterns).

I made a backup of the snapshot file and then deleted because I do not particularly need that snapshot. prune -exhaustive -exclusive ran with no errors. I am now running my normal maintenance prunes, checks, and copy. So far, so good. I will repost here if there is an error.

I was not successful following the recovery instructions in your last paragraph. The file was not present, perhaps because the damaged snapshot was not the most recent - several subsequent backups happened after the damaged one before I noticed the error. Since I don’t need that snapshot, that is OK.

Do you have any ideas on how this damage might have happened and how I can avoid it in the future?

Thanks!

I forgot that only the latest snapshot file is kept in the local cache, so if there is a revision past 4847 then 4847 should have been deleted from the local cache. But this also indicates that at least the local cached copy of 4847 is correct since 4848 depends on this file to make a successful backup.

The corruption is more likely to be caused by a disk error, although I can’t completely exclude the possibility of a bug in Duplicacy. Would you mind sending me the corrupted snapshot file for me to take a look?

I’m not sure quite how to attach it, so added a txt extension and uploaded it here. Let me know if you want it in a different way. Thanks!

4847.txt (550 Bytes)

The file size is right and I don’t see anything obviously wrong. There might be some corrupted bits but without the encryption password it is not possible to find out.

I think these kind of errors can be caught early if you run a check right after every backup.