[rdiff-backup-users] About backups and increments

[Yuri D'Elia]

Hi everyone. I'm successfully using rdiff-backup to perform backups of several
machines. After using it for some time though, I have some questions that I
hope are not in the FAQ ;).

Is the backup procedure crash/interrupt safe? If I'm backing-up some data and
for some reason the program gets killed (say, manually), in what state the
backup will remain? Does the latest snapshot reflect the old state (as if no
backup was performed), a broken state (cannot reliably recover anything), or a
mixed state? Is this state ever recorded as an increment so that I can drop it?

If the backup will be left in a mixed state, what exactly is the state of the
file where rdiff-backup was working before being killed? Old or broken? Will
the old increments still be recoverable?

I want to asses how resistant rdiff-backup is to this kind of problems.

About space requirements: I assume the space required for the backup is:

- the space of the source files themselves
- the space of all the increments
- extra space required to compute the increment?
* Is this space stored on the source or destination drive?  * This should be
the size of the file currently computed + it's increments right? So should I
assume that to backup the *second* increment of some space X (where X can
possibly be just one huge file) I need at least X * 2 space for the backup -
just for temporary files?
* This brings me back to my first question: what happens when the destination
is full?

I need to be able to *reliably* set space reservations before being caught with
an incomplete backup.

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? rdiff-backup is cpu bound for me one some machines for this
reason.

A request: increments pruning. --remove-older-than is fine most of the times,
though I would like an extra knob:

--keep-increments N (where N is the number of most recent increments to keep,
irregardless of time).

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

--remove-older-than X --keep-increments 2

would do the job. This would also allow to indirectly keep N increments
regardless of the date:

--remove-older-than 0D --keep-increments N

It's very important (in my opinion) that, if I have the space, I always keep at
least 2 old copies around at all times. I'm prepared to implement this myself
if that would help getting this adopted.

Sorry for the long post :), and thanks for rdiff-backup.