Question

4

Deja-dup: Invalid data - SHA1 hash mismatch for file

rated 0 times [ 4] [ 0] / answers: 1 / hits: 4725 / 2 Years ago, wed, september 28, 2022, 9:13:03

I have backed up my data with deja-dup utility and made clean install of 12.04.

But when I tried to restore the back up I got this error:

invalid data - SHA1 hash mismatch for file:

 duplicity-full.20120508T105537Z.vol12.difftar.gz

 Calculated hash: 8ae69af39a566823309fae86142ae3a2af16358d

 Manifest hash: 6a332f406b0842f229e2122921c0e4c97c4f76bd

I tried to remove cache and perform manual restore with different options but it fails every time on same files. I put attention that those files are smaller then other. They are about 30Mb while all other files are 51Mb.

Total size of backup is about 35Gb.

Backup is stored on external USB drive with FAT file system.

No encryption used

Is it some workaround exists?

Is it possible to exclude specific files from restore?

Any ideas?... As you understand, I REALLY NEED this data!...

Thanks

Update:
@Nirmik, @Eliah Kagan:

I tried to restore from local directory and UbuntuOne as well. The same problem. I can restore some files but never succeeded to restore full backup. I tried to perform those actions with test backup of some small directory... the problem is consistent.

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

wenceslockro

Add To Favorites

Follow

Total Points: 494

Total Questions: 127

Total Answers: 97

Location: Chad

Member since Mon, Dec 5, 2022

1 Year ago

answered 2 Years ago tersle · Accepted Answer

It seems that you hit a known bug: deja-dup bug 826389, bug 487720.

Quoting from the second link it seems that your data corruption is not given by hardware, but is completely software-related:

This can happen when a volume file was not completely written to the backend before duplicity was interrupted (say, shutting down the machine or whatever). When duplicity resumes the backup next run, it will start with the next volume. The half-complete volume file will sit on the backend and cause this error later when restoring.

You can manually recover from this by either restoring from your older backup sets or by restoring individual files that don't happen to be in the corrupted volume.

Two other guys from the first link says:

There are two ways around this. You can try to restore from the backup from before the corrupted one. So try restoring from older backups.

You can also try to avoid the specific volume by restoring all the files from the backup set except the ones in the corrupted volume.

and:

Thank you very much. What I did was [duplicity --file-to-restore ....] and I restored the important files.

I've never used deja-dup or duplicity, but it seems that the most reasonable solution here is to automatically restore intact volumes with deja-dup, and then proceed with intact files inside a volume restoring them one by one with duplicity --file-to-restore ...

Hope this helps.