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

[Robert Nichols]

On 08/22/2011 11:19 AM, Yuri D'Elia wrote:
> 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've never looked at the code (I've heard rumors of people being treated for
cancer of the eyeballs after prolonged viewing.), but conceptually it's just
a delicate process that must be done very carefully lest interrupting the
regression leave things in an even worse state.

There's a very basic outline of the data storage at
http://www.nongnu.org/rdiff-backup/format.html .

> > > --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.)

The "nnnB" notation for counting back by backup sessions is documented as
an alternative to a timestamp, just not in the section dealing with
--remove-older-than.

> 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.

I would still want some way to verify what will be removed before committing
to that irreversible action.  And then of course there would have to be some
way to bypass that when invoking that function from a script.  Whatever.
That would rank pretty low on the list of things I'd like to see different.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.