rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Bailout on broken rdiff-backup-data/ dir


From: Ben Escoto
Subject: Re: [rdiff-backup-users] Bailout on broken rdiff-backup-data/ dir
Date: Sun, 16 May 2004 20:04:43 -0700

>>>>> Ingo Ruhnke <address@hidden>
>>>>> 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

Attachment: pgpMBVdTEHqH_.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]