On Mon, 22 Aug 2011 10:54:48 -0500 Robert Nichols <[email protected]> wrote:
> Recovery from a failed or interrupted session is reliable, but time consuming. > The next time you try to do any operation on that archive, rdiff-backup will > insist on first performing a regression of the failed session back to the > previous state. There is also the "--check-destination-dir" action, which > does only the regression, if one is needed. For a large backup set, the > regression takes a *long* time. Hi Robert, thanks for the response. Can I ask why does it take long? Is there a document/little explanation somewhere that tells how rsync-backups keeps its internal format/sessions/etc? > I'm not aware of any extra space needed for computing the increment, but the > increment itself, of course, does need to be stored on the destination drive. > If the destination drive runs out of space, the rdiff-backup session will > fail. Ok, I only think to know more about the rdiff-backup storage to answer that question better myself. > > About backup speed. rdiff-backup doesn't seem to support both backupping > > *and* > > pruning the increments at the same time (yes, I've read the man page). > > Though > > this sounds like a very sensible thing to do: knowing that you will prune > > several old increments, you can avoid to calculate the reverse diffs. Has > > this > > been considered? > > There's not much point in combining those two, totally independent actions. > Computing the reverse diffs for session N vs. session N-1 is totally > independent of the existence (or lack thereof) of earlier sessions in the > archive. Ok. > > --keep-increments N (where N is the number of most recent increments to > > keep, > > irregardless of time). > > You can already do that. Though the manpage doesn't mention it, you can also Whoa. Can we fix the manpage? :) > use a "B" suffix to specify the number of sessions to keep: > > rdiff-backup --remove-older-than 30B /path/to/archive > > will retain the most recent 30 sessions. (Yes, you'll probably need to > include "--force" with that.) Yes, I basically always use --force with --remove-older-than. Using --force feels "wrong" IMHO, since it *is* the intended action of --remove-older-than to remove possibly more than one increment. > > Let's say I want always to keep at all times at least 2 increments (or 2 > > months, if that matters), I have no way to do that directly (I could list > > the > > increments and calculate the time myself, but that's ugly). > > Hey!! Some of us scripting veterans really get off on "ugly"! Hah, I know I do too, but I was hoping I could avoid that. Having --remove-older-than ?B still doesn't allow me to avoid the ugliness. > # Each Sunday, delete backups older than the previous Sunday, but > # always retaining at least 6 backups. Exactly what I intended to do. I would love something integrated in rsync-backup, since it seems such an obvious scenario to me. Maybe a combined specifier? --remove-older-than time-spec[,?B] > Bob Nichols "NOSPAM" is really part of my email address. > Do NOT delete it. I always loved that trick, but does it still work? ;) _______________________________________________ rdiff-backup-users mailing list at [email protected] https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
