Re: Re: [rdiff-backup-users] can rdiff-backup be stopped / paused / restarted? - HOWTO?

[Chris Wilson]

Hi Maarten and devzero,

On Mon, 14 Jan 2008, Maarten Bezemer wrote:

> On Sun, 13 Jan 2008 address@hidden wrote:
> 
> > when rdiff-backup is really cancelled while running there is no return
> > and rdiff-backup will need to recover first on the next run......
> 
> Although I can understand why it is done this way, I'm not entirely 
> convinced that it can't be done differently. I mean: resume isn't 
> considered the Right Thing because rdiff-backup is supposed to be a 
> 'snapshot' at 1 point in time. But in practice, if you have slow links 
> or a lot of stuff to back up, the data backed up at the end of the run 
> may be from a much later time than the data backup up at the beginning 
> of that run. This wouldn't be much different from starting a backup, 
> network link breaking, and resuming 5 minutes later. Yet, this isn't 
> supported... :-(
> 
> Not knowing the python code very well, I'm not sure if saving checkpoint 
> data in the exception handler is feasible. Same goes for reading 
> checkpoint data and continuing from that point. Would be nice to have, 
> but I'm not expecting anything like this to happen before we get 
> increment-merging ;-)

As I see it, the problem is that rdiff-backup saves increment files as it 
goes along updating the remote repository. It does this in such a way that 
it can undo the increments if necessary, with --check-destination-dir, but 
I think it might not be able (currently) to:

* determine which increments have already been applied when restarting the 
backup, and not apply them again; and

* handle the case where a file that was incremented during the last run 
has subsequently changed and needs to be incremented again (merging 
increments); and

* handle the case where the increments created so far do not match the log 
file written so far (because the two cannot be updated atomically in 
step).

These problems are not impossible to solve, but backup software is tricky 
to get right and also very very important to get right, and I can 
understand the authors' reluctance (so far) to try this.

In most cases, it's not actually necessary either. Careful bandwidth 
management (QoS) on your Internet connection can ensure that your backups 
can run for as long as necessary without needing to be interrupted and 
without disturbing other traffic.

We do this at the company that I work for (I implemented it) and it works 
reasonably well, although rdiff-backup has some other problems as well, so 
we're looking at other solutions. So far I'm not aware of anything else 
that has all the nice properties of rdiff-backup (which I really want), so 
we're stuck with it (and I don't know python to fix rdiff-backup myself).

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |