How does duplicity currently store files in the tarballs?

Asked by Lars Volker on 2009-09-11

As stated in another question, i try to restore data from a set of files, of which one (the last one of the initial full backup) seems to be broken. I've read in the manpage about the way duplicity stores files in the tarballs. I also managed to un-gpg all the files in the target-dir. However i only find chunks of 64kb size of the files inside the tarballs.

Is this due to rdiff? I never used that before, so may one could give a hint on how to restore my data using rdiff, i know how to use tar and co thou.

Question information

Language:
English Edit question
Status:
Answered
For:
Duplicity Edit question
Assignee:
No assignee Edit question
Last query:
2009-09-11
Last reply:
2009-09-11

Did you save a copy of the original backup, or has it been destroyed?

What was the error? Was it consistent on subsequent tries? Maybe we can work through this.

As to manual recovery, that is difficult. Tar is used for storage, but there's a lot undocumented still in the code, so I can't say for sure if manual recovery is even possible. With a little work, I might be able to find a way to ignore the particular error and continue the restore. For certain cases that works.

Whoops, that should be "needs information", not "answered".

Lars Volker (lv) said : #3

Thanks for the quick reply.

I made a backup to my usb-disk, so there was 1 full set and 6 or 7 incrementals. Then i rsynced that to a server.

Both of the filesets repeatedly gave the gpg-error: gzip "incorrect data check". This happen during extraction of the last file in the first archive. I made them of size 1G for the full run, 25MB on incremental runs. Was that wrong?

What i now did to recover the data was (with lots of trial-and-error) the following:
- Un-GPG all the files
- Remove the lines containing the word "Hash" from all files ending in ".manifest"
- Run duplicity with --no-encrypt

This way, it seems i could recover most of the data, as the error was located at the end of the first archive of the full-backup.

The error occurred with both of the filesets and there was no checksum-error reported, so i guess, the files were in fact sound.

Should i open a bug from this question? Do you need more information. I now have my data back. :) yay!

Glad to hear you got your data back! You'll be glad to know that we're working on par2 support for 0.7.0, so this kind of thing should not happen any more.

As to a bug report, yes, and please include a pointer to this workaround. Quite clever!

Can you help with this problem?

Provide an answer of your own, or ask Lars Volker for more information if necessary.

To post a message you must log in.