[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Sliding window backup strategy?
From: |
Lars Marowsky-Bree |
Subject: |
Re: [Duplicity-talk] Sliding window backup strategy? |
Date: |
Sun, 5 Oct 2008 20:44:29 +0200 |
User-agent: |
Mutt/1.5.17 (2007-11-01) |
On 2008-10-05T11:51:14, Timothee Besset <address@hidden> wrote:
> I am completely on board with the idea that a full backup should only be
> performed once, and that the full backup should be maintained with
> little to no extra incrementals to re-apply.
>
> As far as implementation, a sliding window as you described is basically
> doing a full backup but spreading it over time so it hurts "less" ..
Agreed, see my other mail.
> When I suggested this same basic feature (only one full backup ever) ..
> some months ago on this list, I was thinking more along the lines of
> 'reverse delta' .. for instance like subversion does. The basic idea is
> that you always keep the latest version of the file and you maintain
> deltas going back in time towards earlier versions. That way you can
> drop the old stuff as you see fit.
>
> I think however that such an implementation requires some server side
> intelligence, and it would be pretty hard to fit in duplicity's approach
> of a dumb untrusted remote storage (which was also one of the aspects
> that initially drew me to it)
I know how to do it with server-side intelligence. That's easy ;-)
That is essentially what my home-brewn scripts did. On the server side,
I rotated the last backup out of the way, created a tree of hard-links,
and rsync'ed into the new tree (rsync knows how to handle hardlinks).
That provides _trivial_ access to older revisions, while preserving the
lowest-possible-overhead on backup thanks to rsync.
Whenever I no longer wanted some particular snapshot, I could simply
delete it. The filesystem took care of everything else.
However, you're perfectly right - this requires server-side
intelligence, and access to the raw data on the server (trust issues),
and it's also less space-efficient than storing rdiffs for the most part
(each modified file would take the full space, _every time_); which is
exactly what I'm trying to move away from.
Thanks,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
- [Duplicity-talk] Sliding window backup strategy?, Lars Marowsky-Bree, 2008/10/05
- Re: [Duplicity-talk] Sliding window backup strategy?, Serge Wroclawski, 2008/10/05
- Re: [Duplicity-talk] Sliding window backup strategy?, Lars Marowsky-Bree, 2008/10/05
- Re: [Duplicity-talk] Sliding window backup strategy?, Timothee Besset, 2008/10/05
- Re: [Duplicity-talk] Sliding window backup strategy?,
Lars Marowsky-Bree <=
- Re: [Duplicity-talk] Sliding window backup strategy?, Colin Ryan, 2008/10/05
- Re: [Duplicity-talk] Sliding window backup strategy?, Lars Marowsky-Bree, 2008/10/05
- Re: [Duplicity-talk] Sliding window backup strategy?, Peter Schuller, 2008/10/06
- Re: [Duplicity-talk] Sliding window backup strategy?, Peter Schuller, 2008/10/06