how to unbungle a bad backup

[Ben Escoto]

Jamie Heilman wrote:

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

That is the right syntax.  I'm not sure why there would be .missing 
increments:  the diffs go backwards in time, so if you delete a lot of 
files, you should get a lot of .snapshot increments; if you create a lot 
of new files, you get a lot of .missing increments (to restore the old 
state you have to delete the files marked as .missing files).  Also, can 
you tell me the exact error message?  I can't tell which exact one you 
mean.  But I don't think you should have lost any data because of the 
full HD, because when a file gets deleted, rdiff-backup just copies the 
file into a .snapshot increment, and then deletes the file. 
 Fortunately, the .snapshot file gets copied before the original file is 
deleted (it's kind of hard to screw that one up) so if lack of space 
prevented the .snapshot from getting created, the program would abort 
leaving the original the way it was.  But I guess things aren't working 
the way I planned if you are getting recovery errors.

    I might normally be able to give you a better answer but I'm 
travelling (will get back next weekend) and don't have non-painful 
access to my system.


--
Ben Escoto