rdiff-backup-users
[Top][All Lists]
Advanced

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

Re: [rdiff-backup-users] Resuming rdiff-backup after crash


From: Ben Escoto
Subject: Re: [rdiff-backup-users] Resuming rdiff-backup after crash
Date: Sun, 04 May 2003 21:48:29 -0700

>>>>> "TH" == Trevor Harmon <address@hidden>
>>>>> wrote the following on Sun, 04 May 2003 22:22:46 -0500

  TH> When I got an xterm back and restarted rdiff-backup (with the
  TH> exact same parameters), I saw this message:

  TH> "Last backup dated Sun May 4 13:08:14 2003 was aborted, but we
  TH> aren't resuming it."

  TH> What does this mean? Is rdiff-backup trying to resume the backup
  TH> cleanly? That would be great if it is, but then again, if you do
  TH> Ctrl-C, you get a nasty-looking Python stacktrace, so I really
  TH> don't know how rdiff-backup is designed to handle crashes. (I'm
  TH> using 0.10.2.)

  TH> It would really be cool if rdiff-backup were fault-tolerant and
  TH> could pick up a backup job no matter when it dies. That would
  TH> also allow a pause-resume feature, which I don't think exists
  TH> now. (e.g. pressing Ctrl-C halts the current backup, then doing,
  TH> say, "rdiff-backup --resume" picks up where it left off.) Not
  TH> exactly a high-priority feature, but something that would be
  TH> nice to have.

The versions between 0.5.x (?) and 0.10.x tried to resume certain
backups.  Whether or not a backup resumed the next time it was run
depended on various settings (e.g. --no-resume) and how long ago the
aborted backup started.  It was supposed to work about how you
suggested.

But unfortunately that system proved too unwieldy.  rdiff-backup would
have to dump its state to disk every so often (the "checkpoint
interval"), and that state would have to be read and recovered.  It
was just not worth it IMHO.  When newer versions (most of 0.11.x
series) crash, the next session checks the destination dir and reverts
it to the state it was in before the aborted session started.


-- 
Ben Escoto

Attachment: pgpYjiS6teCW5.pgp
Description: PGP signature


reply via email to

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