duplicity-team team mailing list archive

[Peter Schuller <question116587@xxxxxxxxxxxxxxxxxxxxx>]

Question #116587 on Duplicity changed:
https://answers.launchpad.net/duplicity/+question/116587

    Status: Open => Answered

Peter Schuller proposed the following answer:
> 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).

-- 
/ Peter Schuller

You received this question notification because you are a member of
duplicity-team, which is an answer contact for Duplicity.