duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] multi-level diffs; deletions


From: Dan Christensen
Subject: Re: [Duplicity-talk] multi-level diffs; deletions
Date: Tue, 04 Feb 2003 18:03:15 -0500
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu)

Ben Escoto <address@hidden> writes:

>>>>>> "DC" == Dan Christensen <address@hidden>
>>>>>> wrote the following on Mon, 03 Feb 2003 23:53:27 -0500
>
>   DC> 1) From what I've read, duplicity only supports full backups and
>   DC> one level of differential backups.  Is adding one (or more)
>   DC> additional levels of differential backups something that might
>   DC> happen in the near future?
>
> BTW, duplicity is fairly space efficient because it makes diffs
> instead of copying all of changed files.  Multilevel backups may not
> be as necessary as with other schemes.  

Actually, I think that with rdiff based incrementals, one is more
likely to want multilevel backups.  Let me explain.  Suppose you
do a full backup A and then a backup B relative to A.  Now it's
time for backup C, and you are trying to decide whether to do it
relative to A or B.  The advantage of doing it relative to A is
that you only have two tar files to process if you have to restore.
The disadvantage is that backup C will be larger.

If you use an rdiff based scheme instead of the usual method of
backing up entire files that have changed, then the advantage of doing
the backup relative to A is even bigger (since restores are more
complicated, especially in the case of a complete disk failure) and
the disadvantage is even less (since rdiff based backups are smaller).

Put another way, since rdiff based backups produce smaller
incrementals, I'm probably going to space my full backups further
apart than with a traditional approach.  So I'm going to want
multilevel incrementals even more, since without them I'm going to
have to process a long sequence of .difftar files in order to restore
my system.

(Of course, since *I* think this, *I* should implement it.  :-)  If
I knew python and didn't have a new baby, I'd consider it!  And I
agree that the other things on the todo list are at least as
important.) 

> Also, I can't think of
> anything in the architecture which would preclude this
> feature---duplicity would just have to keep signatures for backup sets
> other than the most recent.

I just tried duplicity out, and it seems to do this already.  So
maybe this feature wouldn't be hard to add?

>   DC> 3) In the case of a complete disk failure, what's the
>   DC> recommended way to do a full restore?  Is there a duplicity
>   DC> rescue-disk?
>
> ...  A duplicity rescue disk seems a bit extreme though.

Maybe you can convince some of the standard rescue CD providers
to add duplicity, rdiff, etc.  E.g. KNOPPIX (which already has
amanda, for example) and LNX-BBC.

Best wishes,

Dan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]