Duplicity

Suggestion, hash backup files to insure they are not corrupted

Asked by Alex Robinson

Perhaps this is already done invisibly, but it might be good to have an option that tells the remote backup machine to md5sum (or the like) the backup files and for duplicity to fuss if the hashes of any files have changed from their previous values.

Or perhaps this would be better done outside duplicity as it's likely that many people have done this, themselves, for any number of applications.

Question information

Language:
English Edit question
Status:
Solved
For:
Duplicity Edit question
Assignee:
No assignee Edit question
Solved by:
Alex Robinson
Solved:
Last query:
Last reply:
Revision history for this message
edso (ed.so) said : 		#1

if you haven't disabled encryption, gpg takes care of that ... Tempered files will break the restore/verify ... ede

Revision history for this message
Alex Robinson (alex-launchpad-tranzoa) said : 		#2

From the man page I got the impression that verify would check the current state of the "source" - the data-to-be-backed-up - with the current state of the backup. I would expect that the backup's sig files would contain data sufficient to handle this job. And, if the sig files are duped on the source machine (so that they do not need to be sent back to the source machine for verification), then the verify operation would only need to hash them on both ends to insure that they are the same - before running a check against the local sig files and the source data. Hence, to verify there is no reason to even read the actual data backup files on the remote, backup machine. Or, does verify both do a remote hash of the sig files on the remote machine AND validate on the remote machine that the sigs match the backup data files as they exist at the moment? If so, then gpg would not need to be involved (assuming that the sig files include hashes of the encrypted data).

Revision history for this message
edso (ed.so) said : 		#3

there is no remote action with duplicity. backends are only used to store data. don't know how you got your impression.

citation from http://duplicity.nongnu.org/duplicity.1.html ->

verify
    Enter verify mode instead of restore. 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.

<-- citation end

verify restore a file, compares it with source and does this with the next again and again ..that's it.

if files were tempered with, gpg would fail .. ede

Revision history for this message
Alex Robinson (alex-launchpad-tranzoa) said : 		#4

Ah. OK. Thanks. Yes, then a verify would, like a full restore, take several weeks on the backup I'm concerned with. (Real restores for this backup would be done by fedex.)

Anyway, even if a validation function were in duplicity, it would only be usable on certain URL schemes, so it would be confusing. Bad idea. :)