Question #116587 on Duplicity changed: https://answers.launchpad.net/duplicity/+question/116587
Kenneth Loafman proposed the following answer: Peter Schuller wrote: >> I am looking for a way to verify that the backup could restore without error. >> >> I now use Duplicity as my only backup mechanism. It would be excellent if, >> once every so often, I could run something that: >> (1) did a backup (so that we knew the remote location *should* match the >> local files); >> (2) pulled down all necessary files from the remote backup location (roughly >> file by file, so that the minimum necessary had to be stored in the local >> temporary location); >> (3) extracted the most recent versions of each file from the backup archives; >> (4) compared each file from the backup archives to the local versions; and >> (5) reported any errors or differences. >> >> Does the "verify" option in duplicity provide this functionality? > > You may wish to wait for Kenneth to weigh in, but I believe verify is > intended to do just that - but it occurs to me that I am not sure how > this interacts with the caching of manifest information. Indeed, > testing it, it appears to be the case. Modifying a file in the cache > directory locally makes the verify fails; this implies the verify will > also succeed (i.e., fail to verify) if the server-side manifest is > corrupted and the local cached version is used during verify. I'll > file a bug on that. > > I do think though that if you eliminate the use of cached data verify > should do what you list; or at least that should be the intent. > > It occurs to me that there should also be a simple method of disabling > the use of the cache (and perhaps simply have verify imply that). [resend with complete CC list] Going to jump in here rather than later in the thread where its messy. Duplicity does verify the contents of the archives *as they were*, it does not do a comparison with the contents on the filesystem. Verify is done by comparing the archive contents with the stored signatures, i.e. the original file with its hash value. The assumption is that the filesystem will probably change shortly after backup. What you look for in a verify is a check to see if the backup is stored properly and can be restored. If you want a comparison function, you'll need to restore and compare the original with the restored files, or provide a direct comparison function for us to integrate into duplicity. If you want to test verify, backup to a local file system, hexedit one of the archives and try to verify. It will fail to verify. You can modify the original files at will, and verify will succeed, as it is designed to do. ...Ken -- You received this question notification because you are a member of duplicity-team, which is an answer contact for Duplicity. _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
