Verify should not compare anything with filesystem (mtime, permissions or file contents etc) unless --compare-data is used

Bug #1354880 reported by Aaron Whitehouse
20
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Duplicity
Fix Released
Medium
Unassigned

Bug Description

Refer to the mailing list discussion here:
http://lists.nongnu.org/archive/html/duplicity-talk/2014-07/msg00016.html

By default verify should not be concerned with the current (post-backup) 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.

The comparison of dates/modtimes should only be carried out if --compare-data is used. On that basis, verify should 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.

Once this behaviour is implemented, the man page should 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)."

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

Please find attached a Bash script that shows the current behaviour of verify.

Changed in duplicity:
importance: Undecided → Medium
milestone: none → 0.7.01
status: New → Fix Committed
Changed in duplicity:
status: Fix Committed → Fix Released
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

For the records, this was fixed in:
http://bazaar.launchpad.net/~duplicity-team/duplicity/0.7-series/revision/1038
"* Fix duplicity verify to ignore the file system when globals.compare_data is
  False. This means that verify only validates the viability of the backup
  itself unless --compare-data is specified."

Revision history for this message
falloutphil (falloutphil) wrote :

Hi,

Realize this is an old bug, but I'm coming up against a similar issue and I wanted to check expected functionality.

(I'm using Ubuntu 16.04 which I've checked the source and it appears to contain the fix above).

The specific edge-case I have is:

duplicity 0.7.06 (December 07, 2015)
Args: /usr/bin/duplicity verify -v5 --no-encryption -tnow --file-to-restore=foo_dir sftp://server://backups/duplicity /tmp/some_dir

2 questions:

1) Given the now clarified use of verify without the --compare-data means no comparison is made with currently held local data, I assume the /tmp/some_dir directory is merely a dumping ground for duplicity to use to restore and regenerate the signatures for the time and file-to-restore given? i.e. it explodes foo_dir here temporarily to generate it's signature against the stored version? There is no expectation for /tmp/some_dir to contain anything, but I assume it must exist, and I assume it should be empty as we're not doing a comparison with current local data?

2) What I found confusing is that if I provide file-to-restore with a directory that had existed in a previous backup, but had since been removed from from the most recent backups, duplicity returns success on verification. Even though the file-to-restore doesn't exist in the backup at the restore point requested:

Using temporary directory /tmp/duplicity-xyPe8Z-tempdir
Deleting /tmp/duplicity-xyPe8Z-tempdir/mktemp-qO64XD-1
Processed volume 1 of 2619
Verify complete: 1 file compared, 0 differences found.
quantile@nyqctlr03:~$ echo $?
0

Given the use case that I might want to know if a given restore point contains a given folder (or if I must find a different restore point) the returning of success for a specified file doesn't seem intuitive to me.

Is there a way of verifying a given directory or file exists, at a given restore point, and that the data is intact in case of requiring a restore?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.