Re: [rdiff-backup-users] About backups and increments

[Yuri D'Elia]

On Mon, 22 Aug 2011 10:54:48 -0500
Robert Nichols <address@hidden> 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? ;)