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