Re: [Duplicity-talk] Big bandwidth bill from Rackspace

[lists]

> On 11.06.2013 00:56, Nate Eldredge wrote:
> valid point. btw. the next release will have a --compare-data switch which
> was not exposed before to actually compare local path with the backed up
> version bit by bit.
>
[...]
> duplicity's current verify is a combination of both. we should probably
> make that clearer, or clean it up by separating the actions properly
> compare - actually compare local path with a restored copy
> verify - simply restore and compare against the saved checksum
>
> but that still would download the volumes. giving compare a parameter to
> compare against the manifest files, saving traffic, would allow to check
> for changes. but that is essentially what --dry-run is doing already. so
> why bother?
[...]
> ..ede/duply.net

For what it is worth, I completely agree that this should be better split.

This issue came up in a question that I raised a few years ago:
https://answers.launchpad.net/duplicity/+question/116587
and my proposed change to the man page to make this clearer:
https://bugs.launchpad.net/duplicity/+bug/644816
(which didn't happen). We also discussed a "test-restore" option that
sounds to match the new comparison that you mention.

I am currently hitting issues because the verify throws an error message
when a local log file changes between the backup and verify, which in this
instance I don't care about so long as the backup version can successfully
restore and matches the checksum.  Based on the theoretical idea of verify
(remote archive tested against checksum), I don't think that there should
be any comparison to the filesystem.  That feature is useful, but belongs
more in a separate function like the --compare-data option you refer to.

In case it helps, the way that I address the bandwidth issue is to duply
to the local filesystem and then rsync it off to the cloud - that way you
can run verify each time without downloading the files. Of course, there
is still the risk that the files haven't rsynced properly.

Hope that helps,

Aaron