[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Big bandwidth bill from Rackspace
From: |
lists |
Subject: |
Re: [Duplicity-talk] Big bandwidth bill from Rackspace |
Date: |
Wed, 12 Jun 2013 02:27:52 +1200 |
User-agent: |
SquirrelMail/1.4.22 |
> 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
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, (continued)
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, James Patterson, 2013/06/10
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, edgar . soldin, 2013/06/10
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, James Patterson, 2013/06/10
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, edgar . soldin, 2013/06/10
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, James Patterson, 2013/06/10
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, edgar . soldin, 2013/06/10
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, Joseph D. Wagner, 2013/06/10
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, edgar . soldin, 2013/06/10
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, Nate Eldredge, 2013/06/10
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace, edgar . soldin, 2013/06/11
- Re: [Duplicity-talk] Big bandwidth bill from Rackspace,
lists <=