duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

Peter Schuller wrote:
>> I am looking for a way to verify that the backup could restore without error.
>>
>> I now use Duplicity as my only backup mechanism. It would be excellent if, once every so often, I could run something that:
>> (1) did a backup (so that we knew the remote location *should* match the local files);
>> (2) pulled down all necessary files from the remote backup location (roughly file by file, so that the minimum necessary had to be stored in the local temporary location);
>> (3) extracted the most recent versions of each file from the backup archives;
>> (4) compared each file from the backup archives to the local versions; and
>> (5) reported any errors or differences.
>>
>> Does the "verify" option in duplicity provide this functionality?
> 
> You may wish to wait for Kenneth to weigh in, but I believe verify is
> intended to do just that - but it occurs to me that I am not sure how
> this interacts with the caching of manifest information. Indeed,
> testing it, it appears to be the case. Modifying a file in the cache
> directory locally makes the verify fails; this implies the verify will
> also succeed (i.e., fail to verify) if the server-side manifest is
> corrupted and the local cached version is used during verify. I'll
> file a bug on that.
> 
> I do think though that if you eliminate the use of cached data verify
> should do what you list; or at least that should be the intent.
> 
> It occurs to me that there should also be a simple method of disabling
> the use of the cache (and perhaps simply have verify imply that).

[resend with complete CC list]

Going to jump in here rather than later in the thread where its messy.

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.

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.

...Ken

Attachment: signature.asc
Description: OpenPGP digital signature