[Top][All Lists]

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

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

From: Robert Nichols
Subject: Re: [rdiff-backup-users] About backups and increments
Date: Mon, 22 Aug 2011 14:58:22 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110816 Red Hat/3.1.12-1.el6_1 Thunderbird/3.1.12

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

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

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.

reply via email to

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