[Top][All Lists]

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

Re: [Duplicity-talk] Seeding a remote backup

From: Kenneth Loafman
Subject: Re: [Duplicity-talk] Seeding a remote backup
Date: Fri, 15 Jun 2012 06:26:22 -0500

On Fri, Jun 15, 2012 at 3:18 AM, <address@hidden> wrote:
On 14.06.2012 21:11, Kenneth Loafman wrote:
> On Thu, Jun 14, 2012 at 11:10 AM, <address@hidden <mailto:address@hidden>> wrote:
>     On 14.06.2012 17:07, Andrew Kohlsmith (mailing lists account) wrote:
>     > On 2012-06-14, at 11:02 AM, address@hidden <mailto:address@hidden> wrote:
>     >> that's not what i suggested:
>     >> meant was do new incrementals against the old full to effectively shorten the chain artificially hence minimizing the chance of having a defect volume killing backups after it.
>     >
>     > Oh I understand now; I didn't think you could do that and have Duplicity automatically figure that out. That's a very interesting workaround!
>     actually duplicity just plain stupid checks the backend, sees no incrementals and naturally creates the first based on the latest full.
>     >> anyway, this is a workaround and no solution of course. also it does not protect you from the full getting corrupted, so you additionally need that as a copy in a safe place.
>     >
>     > It'd be nice if you could tell Duplicity to do something to that effect… incremental-chain-length or some such…
>     >
>     yeah it would.
>     that would be like introducing a new type of incremental, root-incremental or base-incremental which is always based on the full before it, ignoring the incrementals inbetween.
> It's called a 'differential' backup, which is essentially a backup of everything that has changed since the last full backup.  We don't do that yet, but it's been requested a couple of times.  It takes up a lot more room than incrementals, but means that there's no long chain.  You only need the last full backup and the last differential.

is it common procedure to base following incrementals on these differentials then?

Normally it's a choice, one or the other, incrementals or differentials.  Although, I can see a scheme where mixing would have its benefits, e.g. full, some incrementals, a differential, more incrementals.  If you based the incrementals on the last full plus last differential you could potentially do one full backup and maintain a reasonably short incrementals chain.



reply via email to

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