© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
I ran into the same problem. duplicity version 0.6.15 (might have been 0.6.14 when doing the backup).
I used backintime for years until december 2011, found deja dup, and deleted the plain backup after a successful backup with deja dup.
What a mistake.
After an update the system broke and was not bootable.
No problem, as i assumed the backup was there.
I ran into the SHA1 mismatch issue. I have 699 .difftar.pgp files out of which 7 could not be processed with duplicity.
I tried out the instructions from https:/
Micheal's instructions take you to the point where the files are spread onto two folders multivol_snapshot and snapshot , the first one containing one folder per file, which then contains 64kb parts of the actual file.
As I wanted to restore as much - and as good - as possible, I looked for scripts that do the 'cat' automatically .
I found 2 or 3 scipts, and I tested the one from here
https:/
on the 70GB of original data. One run takes several hours.
It creates the files, but something goes wrong.
Lets say an Image was spread on 4 blocks. If I want to view that image, half of it looks ok, the rest ist missing. Or the image looks picassofied. Funny, at times if
*it just wasn't the only backup of past 10 years*
This person describes a similar behavior.
https:/
I don't mind loosing business docs, even if not all of them are in the companies data centre.
I don't mind loosing many hundreds of source code files, I am sure I can redo that.
But the pictures?
So obviously the question is: Is there a chance to reassemble the blocks in a way that the resulting jpeg files are not corrupted?
Or alternatively: Does anyone know a data curation solution that detects such corruptions?
Possibly the data is present, at least for 70,80,(95?) % and it is the recombining of the blocks that creates the problem.
Truly, any help and hints appreciated.