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
https://code.launchpad.net/~ed.so/duplicity/manpage.verify
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):
https://answers.launchpad.net/duplicity/+question/116587
"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