Ingo Ruhnke <grumbel < at > gmx.de>
wrote the following on Mon, 08 Mar 2004 11:56:08 +0100
I am using:
$ rdiff-backup --version
rdiff-backup 0.13.3
I am not 100% sure how the rdiff-backup-data directory got broken, but
what happened was this. I was running rdiff-backup on an unregular
basis, normally a few times a week. Then one day my hd or the IDE bus
got crazy:
----
...
blk: queue f084ef3c, I/O limit 4095Mb (mask 0xffffffff)
hdg: dma_timer_expiry: dma status == 0x20
hdg: timeout waiting for DMA
...
----
The hd's itself worked fine again after a reboot, but reiserfs got
broken and required a --rebuild-tree. Ok, so I did that and everything
was back to normal. The filesystem containing the rdiff-backup data
should not have been mounted while this has happened, but I am not
100% sure on that, but anyway, it got broken too and now I am being
unable to backup, the rdiff-backup output looks like below. Is there
any way I can let rdiff-backup fixup the broken tree or do I have to
completly 'rm' it and start from scratch (not such a good idea, since
I might need some of the data in there, due to the --rebuild-tree
which broke some files):
$ rdiff-backup -v7 --exclude-globbing-filelist=/home/ingo/.backup-excludes /home/ /mnt/backup/home/
...
Regressing file ingo/cvs/winex/wine/programs/winedbg/lex.yy.c
...
File "/usr/lib/python2.3/gzip.py", line 308, in _read_eof
raise IOError, "CRC check failed"
IOError: CRC check failed
Probably one of the increments (the last one in particular) of
ingo/cvs/winex/wine/programs/winedbg/lex.yy.c got corrupted, and
rdiff-backup can't gunzip it. It's not unheard of for ReiserFS's
--rebuild-tree to corrupt files.
If you can't gunzip that increment manually, then the data in it may
have been lost. I think if you delete/move-aside it and all previous
increments for that file (since the previous ones depend on that one)
the next backup will go through. But you will have lost the history
for that file.
Sorry for the late reply; I realize this is probably too late for you.
--
Ben Escoto
