duplicity-team team mailing list archive

[Rodrigo Alvarez <question163116@xxxxxxxxxxxxxxxxxxxxx>]

Question #163116 on Duplicity changed:
https://answers.launchpad.net/duplicity/+question/163116

Rodrigo Alvarez posted a new comment:
After updating to the latest version of duplicity and increasing the max
number of open files to 500,000 (half a million) duplicity still stopped
the verification process with message OSError: [Errno 24].

I then started verifications (using the patched .manifest as suggested earlier) of prior dates (--time yyyy/mm/dd) and duplicity churned for hours before reporting another cryptic GPG error: 
===== Begin GnuPG log =====
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: encrypted message has been manipulated!
===== End GnuPG log =====

Using different dates, resulted in shorter or longer runs and more
volumes processed but the result was the same.

Eventually I ran a verification to a date prior to the corrupted
manifest, the one with the missmatched hash, and voila! Verification
completed and then a restore to that date was successful.  I will assume
that some volumes associated with the mismatched hatch were somehow
damaged even though GPG could manually decrypt them.

Although I was lucky this time and I only lost some history (and a lot
of time), duplicity failed to 1) detect there was a problem during the
normal backup cycle and notify it and 2) provide a clear indication of
why verification was failing and which files/volumes where being
affected-event at -v9.

I'm now updating my backup script to run frequent verifications of my
backends.  This is something I can afford because I run a local file
server.

Overall my gratitude goes out to Ken and Edso for helping through this
process and suggesting valuable pointers.

-- 
You received this question notification because you are a member of
duplicity-team, which is an answer contact for Duplicity.