> 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?