duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] Seeding a remote backup


From: edgar . soldin
Subject: Re: [Duplicity-talk] Seeding a remote backup
Date: Fri, 15 Jun 2012 10:18:49 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120604 Thunderbird/13.0

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?


..ede/duply.net



reply via email to

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