Re: [Duplicity-talk] Behaviour/Man page of --verify and --compare-restore (was Big bandwidth bill from Rackspace)

[edgar . soldin]

On 21.07.2014 23:06, Aaron Whitehouse wrote:
> 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.

not true as far as my knowledge goes. when implementing the --compare-data 
switch, it was switched off permanently before, i had a look and afaics it 
compared backed up version vs. actual file in source.

try for yourself. make a backup change a file in your source. run a verify.


> 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.

totally agree here. there should be a difference between 
- compare, actually compare to current source
- verify, just check that the backup is healthy

but as always, nobody hacked it so far..

> 
> 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."

not according to my tests. it complains about changed time stamps and even data 
if you enable the --compare-data switch.

> 
> 
> 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.

jupp

> 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.
>> <--"

yeah, i just camer to terms with the status quo, which is a bastard that does 
kind of both (compare & verify)

> 
> 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.

i'd rather have different commands. namely verify and compare.

> 
> 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, 

check the source first.. duplicity surely does check the volumes against a 
saved checksum so it won't try restoring from a corrupt volume. i didn't see no 
comparison against a saved checksum in the verify code. might be there and i 
just do not remember it.

> 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)."

maybe a bit longish, but we can work on that once the new behavior made it into 
duplicity.

all in all, the purpose of the manpage change was to warn the user that he is 
generating traffic, which it does as far as i am concerned :)

..ede/duply.net