how to unbungle a bad backup
Jamie Heilman
jamie@audible.transient.net
Sun, 14 Apr 2002 19:33:42 -0700
Ben Escoto wrote:
> Let's introduce some names:
>
> t - the time of the last good backup
> A - the state of the source directory at the time t
> B - state of the rdiff-backup target directory right after t
> C - current state of rdiff-backup target directory
>
> So B = A + increments older than t, and you want to recover B, to
> pretend that the bad backup never happened?
You got it. Right on the money. I want a way to go back in time... I
also want a way to stop time. And I want infinite beer. But one
thing at a time, backups first.
> So in theory after rdiff-backup failed because of lack of space, you
> still should have been able to recover A, because C should still be
> in a consistent state.
Well, the bad news is, C isn't in a consistent state. I can recover
most of it, but there are 4 directories that have fatal errors. To
compound matters - I don't have the space (data set of ~60G with 30
days of incrementals yeilding about ~97G used on my 101G RAID5 array).
Although if I could around the inconsistencies I could make the space
because I can always recreate my source mirror (which is created via
rsyncing a lot of machines to my backup "server" as it were). Anyway,
the 4 directories which seem broken all have .missing increments as
well as .dir increments stamped with the bad backup date. When
rdiff-backup dies it always does so with a "file doesn't exist error"
when trying to restore. Perhaps I'm doing it wrong? I was just using
the command:
rdiff-backup -v 5 clover.2002-04-12T01\:50\:34-07\:00.dir /ext/restored/clover
to restore the 'clover' directory.
> If you want to reconstruct B, and you have enough space, it seems
> like you can get B by first restoring A using C, and then making an
> rdiff-backup-data directory under A, copying all the increments from
> C to A/rdiff-backup-data except the most recent ones made while you
> were asleep. (All the bad increments should contain something like
> 2002-04-13_03:44:23 or whatever, so they should be easy to exclude.)
Yeah makes sense.
> delete increments other than the oldest ones, but I keep hoping the
> rdiff people will make it much easier on me by adding a 'compose
> diff' feature, where two diffs can be composed to create a third
> without any of the original files.
indeed, that would be slick
--
Jamie Heilman http://audible.transient.net/~jamie/
"It's almost impossible to overestimate the unimportance of most things."
-John Logue