Rdiff-backup Crc Error

2007 21:33:13 -0800 (PST) I'm not sure where this original post went to in the archives, but we have had the same problem. Below are 2 reposted messages on the subject from my sent-mail which discuss resolution. Hopefully they will find their way to the archive or perhaps be easier to find with your message below this one. -Eric From address@hidden Mon Jan 22 13:35:34 2007 -0800 Date: Mon, 22 Jan 2007 13:35:34 -0800 (PST) From: address@hidden To: address@hidden Subject: CRC check Failed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Status: O X-Status: X-Keywords: X-UID: 4793 We are using 1.0.4 and it has been running stable for many months. Every once in a while this CRC check comes across and in the past, the only way we knew to resolve it is to remove the rdiff-backup-data directory and start over. --check-destination-dir also fails with the same error. After reading the mailing list, they suggest that one of the .gz files is bad. After something like this: (http://www.mail-archive.com/address@hidden/msg01116.html) find dest/rdiff-backup-data -type f -name \*.gz -print0 | \ xargs -0r gzip --test I found that the file dest/rdiff-backup-data/mirror_metadata.2007-01-19T18:30:23-08:00.snapshot.gz was bad. The previous mirror_metadata file "mirror_metadata.2007-01-19T05:52:24-08:00.snapshot.gz" was intact so I copied the good one over the bad one and re-ran --check-destination-dir. Even though I used an older mirror_metadata, --check-destination-dir returned without error. I realize that because I copied an old metadata over a more recent backup's metadata some of the increments may be clobbered or perhaps confused. However, it is possible that the damaged metadata was a backup which never really did anything in which case, no harm done; unfortunately, this is unknown. What kind of metadata confusion/increment errors/restore errors might come up due to this metadata replacement which we should be aware of? Is there a way to check the integrity of the increments? Can rdiff-backup perform restore operations on each file with increments and compare against some metadata md5/sha? Is there a way to keep mirror_metadata's from getting damaged or making the code which handles mirror_metadata more robust to failures? Does anyone have suggestions to avoid these scenarios in the future? Thank you for your help!!! -Eric ================================================ From: address@hidden To: Guenevere Prawiroatmodjo

Nov 2007 23:37:03 -0500 Anyone? I'm starting to get worried, since my backups haven't run for several days now. Is there any way to fix the broken rdiff-backup- data directory? On Nov 1, 2007, at 10:26 PM, Kurt https://lists.nongnu.org/archive/html/rdiff-backup-users/2007-11/msg00008.html Yoder wrote: Hello list I recently started seeing this error on one of my backups. After two backups, it's still appearing: Traceback (most recent call last): File "/usr/bin/rdiff-backup", line 23, in ? https://lists.nongnu.org/archive/html/rdiff-backup-users/2007-11/msg00007.html rdiff_backup.Main.error_check_Main(sys.argv[1:]) File "/var/lib/python-support/python2.4/rdiff_backup/Main.py", line 295, in error_check_Main try: Main(arglist) File "/var/lib/python-support/python2.4/rdiff_backup/Main.py", line 315, in Main take_action(rps) File "/var/lib/python-support/python2.4/rdiff_backup/Main.py", line 271, in take_action elif action == "backup": Backup(rps[0], rps[1]) File "/var/lib/python-support/python2.4/rdiff_backup/Main.py", line 328, in Backup backup_final_init(rpout) File "/var/lib/python-support/python2.4/rdiff_backup/Main.py", line 425, in backup_final_init checkdest_if_necessary(rpout) File "/var/lib/python-support/python2.4/rdiff_backup/Main.py", line 824, in checkdest_if_necessary dest_rp.conn.regress.Regress(dest_rp) File "/var/lib/python-support/python2.4/rdiff_backup/regress.py", line 71, in Regress for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf) File "/var/lib/python-support/python2.4/rdiff_backup/ rorpiter.py", line 281, in __call__ last_branch.fast_process(*args) File "/var/lib/python-support/python2.4/rdiff_backup/regress.py", line 267, in fast_process if rf.metadata_rorp.isreg(): self.restore_orig_regfile(rf) File "/var/lib/python-support/python2.4/rdiff_backup/regress.py", line 289, in restore_orig_regfile tf.write_from_fileobj(rf.get_restore_fp()) File "/var/lib/python-support/python2.4/rdiff_backup/restore.py", line 485, in get_restore_fp return robust.check_

2011 11:47:35 +0200 User-agent: https://lists.gnu.org/archive/html/rdiff-backup-users/2011-08/msg00048.html Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; https://lists.gnu.org/archive/html/rdiff-backup-users/2006-03/msg00035.html rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 Hello, I had some (known) problems with the storage on which rdiff-backup was storing files and now operations which rdiff-backup crc regress the backup state end up with a backtrace and a message like: IOError: CRC check failed 0x4b2247ff != 0x124d9df3L . I know I have some corruption going rdiff-backup crc error on but would like to find and delete these backed-up files and continue backing up while retaining the old backups. I'm fine with losing those corrupted files. Can this be done? reply via email to [Prev in Thread] Current Thread [Next in Thread] [rdiff-backup-users] CRC errors, Ivan Voras<= Prev by Date: [rdiff-backup-users] rdiff-backup tries to read .gvfs even if on exclude list on Ubuntu Previous by thread: [rdiff-backup-users] rdiff-backup tries to read .gvfs even if on exclude list on Ubuntu Index(es): Date Thread

Date: Tue, 14 Mar 2006 20:26:24 -0800 (PST) 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. 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 which should remove all files created during that backup... that *might* leave the mirror in a state where you could perform another backup and things would be OK again... but i suspect it will leave some things incorrect (been a while since i understood this part of the code). 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. 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). -dean reply via email to [Prev in Thread] Current Thread [Next in Thread] [rdiff-backup-users] CRC Check Failed, Mike Bydalek, 2006/03/14 Re: [rdiff-backup-users] CRC Check Failed, dean gau