[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Behaviour/Man page of --verify and --compare-restor

From: Aaron Whitehouse
Subject: Re: [Duplicity-talk] Behaviour/Man page of --verify and --compare-restore (was Big bandwidth bill from Rackspace)
Date: Mon, 21 Jul 2014 22:06:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Sending this again as it doesn't seem the first one made it to the list.

From: address@hidden
On 10.06.2013 21:56, James Patterson wrote:
Thanks. I would suggest:

Enter verify mode instead of restore. This will restore each file from
the latest backup and compare it to the local copy.
If the --file-to-restore option is given, restrict verify to that file
or directory. duplicity will exit with a non-zero error level if any
files are different. On verbosity level 4 or higher, log a message for
each file that has changed. 
it's taken a year but good things etc. here is the change's branch

That does seem a better description of how I understand the behaviour to
work, but I am still not convinced that description is completely
correct or even what verify should actually be doing.

Kenneth explained the design of verify here (comment #13):

"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."
So on that basis, saying that it will restore each file and compare it to the local copy is a little misleading, though the latest manpage does clarify that you need the --compare-data option to enable data comparison. I have suggested some text below. This has also reminded me of a discussion that we have had a few times now. In my view, by default verify should not be concerned with the current contents of the filesystem at all, whether that is actual file contents or timestamps. This is particularly the case now that we have the --compare-data option that people can use if they want this functionality. If you agree, feel free to fast-forward to the end and let me know - the rest of this traverses the various comments we have had on this topic to date, so that we don't go over the ground again. As per Kenneth (again, comment #13): https://answers.launchpad.net/duplicity/+question/116587
"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."
I agree with that design decision, though I don't believe verify will in fact succeed if one modifies original files - as even though the original file contents are not checked (unless the new --compare-data option is used), the timestamps are. As per Edgar (comment #1): https://bugs.launchpad.net/duplicity/+bug/644816 "
we really should remove the functionality that verify in addition to
checking the backups integrity is comparing dates/modtimes with the
backups source.

here a citation from the mailing list lately:
2. Why we get 'Difference found: File etc/resolv.conf has mtime Wed Jan 19 09:49:14 2011, expected Wed Jan 19 00:21:25 2011' lines on this process?
confusing isn't it. For reasons not transparent to me, additionally to
verifying the backed up data, verify also compares the date with the
source. This should be removed from my point of view. It could be part
of a new command compare, which actually really compares backup with source.
Peter Schuller echoed this sentiment (https://answers.launchpad.net/duplicity/+question/116587 comment #16) :
" If the intent of verify is just to verify internal integrity, why is a
file system even involved in the process (i.e., why even compare a file
system hierarchy at all)?"
As I mentioned here (http://nongnu.13855.n7.nabble.com/Big-bandwidth-bill-from-Rackspace-td169114.html#a169136), this causes me issues because duplicity errors when the file-system changes shortly after a backup (Kenneth's "assumption" mentioned above). We now have that new separate command (--compare-data). Consistent with the various comments to date, I therefore propose that the comparison of dates/modtimes is only carried out if --compare-data is used. On that basis, verify would not give an error if the file-system changes after the backup, so long as it can restore the files and they match the signatures from the time of the backup. If we are all agreed conceptually, I will file a bug and have a go at making this work. I would also then suggest the above man page read: "Enter verify mode instead of restore. Verify tests the integrity of the backup archives at the remote location by checking each file can restore and that the restored file matches the signature of that file stored in the backup, i.e. compares the archived file with its hash value at archival time. Verify does not actually restore and will not overwrite any local files. If the --file-to-restore option is given, it will restrict verify to that file or directory. The --time option allows the selection of a specific backup to verify. Duplicity will exit with a non-zero error level if any files do not match the signature stored in the archive for that file. On verbosity level 4 or higher, it will log a message for each file that differs from the stored signature. Files must be downloaded to the local machine in order to compare them. Verify does not compare the backed-up version of the file to the current local copy of the files unless the --compare-data option is used (see below)." Aaron

reply via email to

[Prev in Thread] Current Thread [Next in Thread]