dean gaudet wrote:
On Tue, 14 Mar 2006, Mike Bydalek wrote:
Here's the results of that:
$ find server-root/rdiff-backup-data -type f -name \*.gz -print0 | xargs
-0r gzip --test
gzip:
server-root/rdiff-backup-data/mirror_metadata.2006-03-12T21:46:00-07:00.snapshot.gz:
unexpected end of file
Should I delete this file and re-run the backup then?
hmm... but no CRC error... odd... i wonder if rdiff-backup requires the
contents of that file to regress the failed backup.
This may be an error in the error handling. If you look at the
original message, gzip threw an eof, but raised the IOError "CRC check
failed" - false positive?
if you deleted it you might have to do further surgery on the increments
subdir ... i'm not 100% sure what surgery would be required... but you
*could* try something like:
find dest/rdiff-backup-data -name '*.2006-03-12T21:46:00-07:00*' -type f -print0 | xargs -0 rm
find dest/rdiff-backup-data -depth -name '*.2006-03-12T21:46:00-07:00*' -type d -print0 | xargs -0 rmdir
Well, I haven't deleted the snapshot.gz file yet, so I would like to
hold off on rm(dir)'ing stuff, unless it's a last resort. If you're
sure that this will *only* delete that failed back up files, then I
guess that's not too much of a loss. Preferably I'd like to resolve
this gracefully.
another option is to lose your increment history entirely -- do "rm -rf
dest/rdiff-backup-data" and then use the rdiff-backup --force option to
start again (it'll use the files already in the dest). i know this method
works... i've used it many times.
To be honest, I *really* don't want to do this at all. We keep 30 days
of stuff for our people, and starting over just isn't a viable option.
rdiff-backup really needs to handle this one gracefully i think ... it
should be easy to reproduce by using "kill -9" at random times with an
in-progress backup (which would be a good regression test anyhow).
I agree. Time to fire up vmware and do some testing ;)
-Mike
|