duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] Sliding window backup strategy?


From: Peter Schuller
Subject: Re: [Duplicity-talk] Sliding window backup strategy?
Date: Mon, 6 Oct 2008 23:18:03 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

> The rest of the dependency tracking seems already there - duplicity can
> already identify chunks which are no longer in the dependency tree for
> a full restore, no? remove-* use that information.
> 
> As such, I would venture that it should also be "reasonably easy" to
> identify chunks which have become not completely, but only "mostly"
> obsolete, and then insert check-points into the incremental to be able
> to free those chunks. (Side note: if those were sorted by mtime, it
> seems very likely that over time, chunks would grow stable.)

This removal of things that aren't needed is pretty
basic. Incrementals are simply associated with a full backup, and when
removing a certain window of backup chains, you remove any chain which
has exactly 0 full backups or incrementals outside the window to be
removed.

So there is no smartness of the form that I think you're hoping for,
in the sense of identifying which parts of certain files contain data
on what and what it might be used for.

An idea I was thinking of for a separate backup tool was to simply
have a file store that was independent of each snapshot backup. This
way the bulk data (file contents) would be references on demand from
whichever snapshots contain them, and the actual snapshots themselves
would be completely independent of each other. You could use this to
achieve a rolling window, or an exponential backoff density, or most
other things very trivially by simple keeping the snapshots you want
to keep. 

About the only real complexity of the store would be maintaining the
file contents. Disregarding security that becomes pretty simple as
well, but once you are worried about issues like leaking file length
information and similar you have a bigger problem.

Anyways; having rdiff-backup like functionality in duplicity would
indeed be extremely attractive.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

Attachment: pgpbescfUgwp8.pgp
Description: PGP signature


reply via email to

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