duplicity-team team mailing list archive

[edso <question150909@xxxxxxxxxxxxxxxxxxxxx>]

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

    Status: Open => Answered

edso proposed the following answer:
On 30.03.2011 10:08, ceg wrote:
> Question #150909 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/150909
> 
>     Status: Answered => Open
> 
> ceg is still having a problem:
> Thanks for your reply edso!

no problem

> Since duplicity, keeps volumes it could rename any volume that has not
> changed to be part of the current state. If a file in the volume has
> changed, it could produce a new volume and then calculate a reverse diff
> on the volume.
> 
> Hopefully, with this duplicity should also be able to omit very long and
> slow full backups (with large slowly changing datasets) every x backups
> and when purging older versions.
> 

duplicity diffs are actually a tgz/gpg'd sum of all rsync detected
changes in the backup source. They are only split into volumes to get
handy uniform sized chunks for backup repositories that might need it
(e.g. gmail).

so actually there is no possibility of renaming/reusing anything.
duplicity has to go through the chain and reassemble your data. if
corruption occured, then at least some data is definitely lost. there
are loose plans to integrate redundancy checksumming, but that is far
future.

for now the suggested way to deal with this weakness is to do
periodically fulls to keep chains short and the probability of data loss
small.

ede/duply.net

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