On Tue, 13 Oct 2009 12:40:12 +1000 Alexander Zangerl <a...@snafu.priv.at> wrote:
> not being the upstream author i'd say over-complexity would be a > reason. (and for "letting you manage storage yourself" there's > rdiffdir.) > > i'm happy to forward that bug report upstream, if and when i've fully > understood your request: do you mean that level-1 incrementals should > be possible as alternative to level-n's? (ie. diff against last full, > not diff against last backup) No. The backup level is not something that duplicity should handle as far I'm concerned. The lower-level the better. I've posted a message to the duplicity ML through GMane, but I'll write that again since it hasn't gone through yet (so please, forward it). IMHO, the only option duplicity needs is the ability to specify *which* archive to use as reference. This should be pretty straight-forward: add a flag to "duplicity incremental -t" that allows you to specify a date. Instead of picking the most recent archive, find the archive closest to that date and use that as a reference. The current layout is this: date0: full date1: incr from date0 date2: incr from date1 .... date8: full date9: incr from date8 .... With this parameter I could implement differential archive simply the way tar/dump implements it without additional logic: date0: full date1: incr from date0 date2: incr from date1 .... date8: incr from date0 <= date9: incr from date8 date8 is performed as a delta from date0, not as a full backup. restore, by using date9 will require date8 and date0 (date1-7 are no longer needed and can be removed, thus shortening the chain). Restore should continue to work unchanged. Ideally, if I specify a date, duplicity should pick the closest volume and walk backwards from there. So, by default date9 is used, going back to date8 and 0. If I do: duplicity restore -t date3, date3 is picked, and restore is performed with date2/1/0. Most importantly, I should be able to remove date1-7, since they are a separate chain, and they are not needed to restore the latest volume. Some way to do this would be great, but not necessary. > i can see why this would be good for reliability (instead of a long > chain you'd have a broad forest of level-1s), but storage-wise it > will be worse than the current scheme. Obviously, it's a trade-off. Long chains however have a higher risk of failure, since *all* individual archives are equally important. Restore time is very high too. By shortening the chains with multiple levels you can have history that goes back to years, with day-level granularity just for the last month or so, with only 32/33 archives to consider during the restore (30 days tops, plus a level 1 differential and a full backup). This is pretty much trivial, since this way of operation is usually how differential archives are implemented with bare tar, or dump, by setting a different timestamp. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
