evansb2 Posted February 13, 2003 Report Share Posted February 13, 2003 I'm in the process of switching from a tape-based backup system to firewire hard drives. On the initial backup, everything is peachy. When the second backup came around I got -24201 Checksum errors. I rebuilt the catalog, and everything was fine for a couple of days. This morning I, again, received the -24201 Checksum error. The disk is less than 6 months old and checks out fine. I've experienced errors with both disks (two rotating sets), but one has worked fine since I rebuilt the catalog. I'm going to try rebuilding the catalog onto the internal disk, but this won't help if that disk is the one that needs to be restored. This problem occurs with my 50 GB backup but not my 3 GB document backup set on the same disk. Thoughts? Evans Link to comment Share on other sites More sharing options...
AmyJ Posted February 13, 2003 Report Share Posted February 13, 2003 From the Knowledgebase: http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27313 What causes chunk checksum errors? Retrospect's catalogs are really databases that track the files backed up to your backup sets. To detect corruption, should it ever occur, Retrospect saves each block of data in its catalogs with a checksum, a saved calculation based on the block of data, that allows Retrospect to check data integrity later when it reads the data back. Each time it reads data from a catalog, Retrospect quickly verifies that the data is valid by comparing it with the stored checksum. Should a catalog become damaged or corrupt, you may see one of the following errors: Macintosh Retrospect errors: -24203 not a chunk file or badly damaged -24202 chunk file map missing/damaged -24201 chunk checksum didn't match Windows Retrospect errors: -641 chunk checksum didn't match -642 chunk file map missing/damaged -643 not a chunk file or badly damaged These all basically mean that Retrospect has detected that the catalog file is corrupt or damaged. You will need to rebuild it, or restore it, if you have it backed up somewhere. How does this happen? Typically these errors can been seen if there is a crash or power failure while Retrospect is updating a catalog file. You can also see these errors if you have a configuration problem that is causing data corruption on your hard disk or network. If you have only see this error once, we recommend making a note of it, and moving on. If you have seen it multiple times, then you should work to figure out the source of the problem. Try saving your catalogs onto a different hard disk (we have seen obscure problems with data corruption being caused by specific hard disks). If the problem does not follow your catalogs to the new hard disk, consider the original hard disk suspect. It may be that the drive is corrupting other data as well. Consult your drive vendor's documentation, or contact the vendor for assistance. If the problem follows your catalogs to another hard disk, we recommend changing the computer you are running on, if possible. We have, in very rare cases, seen problems with computers that could not be easily quantified, that consistently led to chunk checksum errors on catalogs. These could be caused by RAM, ATAPI or SCSI bus configuration issues, USB or FireWire or IEEE 1394 conflicts or driver issues, or other failing hardware. These are terribly hard to troubleshoot; if things work well on another computer, we recommend switching the backups to that computer, and investigating what might be causing the corruptions on the original computer. Obviously this would be very complex to do. You may end up being satisfied with having your backups working again in their new configuration. It is up to you. However you troubleshoot chunk checksum errors, the bottom line remains that they are caused by Retrospect's data becoming corrupt. Retrospect itself is not corrupting the data, so your troubleshooting efforts should focus on the other variables, as noted above. Link to comment Share on other sites More sharing options...
evansb2 Posted February 13, 2003 Author Report Share Posted February 13, 2003 Yes, thanks, Amy. I've already read this though. I'm looking for further information. I'm running Retrospect on a Mac 7500 upgraded to G3@375mhz with OS X 10.2.3, a firewire PCI card into an Oxford 911 housing with a Western Digital 120 GB drive. I have the current version of Retrospect. Why would the large catalog be the problem? The smaller document backup works without a problem. Evans Link to comment Share on other sites More sharing options...
evansb2 Posted February 14, 2003 Author Report Share Posted February 14, 2003 Here are the results of my recatalog: + Executing Recatalog at 2/13/2003 12:54 PM To backup set Firewire Backup 1? Bad backup set header found (0x3a000c7c at 6,290,692). Backup set format inconsistency (12 at 6290948) 2/14/2003 1:45:18 AM: 2 execution errors. Completed: 175844 files, 48.1 GB Performance: 63.9 MB/minute Duration: 12:50:17 When the morning backup ran I got the following errors: + Normal backup using Firewire Backup at 2/14/2003 5:00 AM To backup set Firewire Backup 1? - 2/14/2003 5:00:20 AM: Copying Sparky on G4 Desktop? 2/14/2003 5:00:20 AM: Connected to G4 Desktop Trouble matching Sparky on G4 Desktop to Firewire Backup 1, error -24201 (chunk checksum didn't match). - 2/14/2003 5:06:21 AM: Copying kitty on Kitty? 2/14/2003 5:06:21 AM: Connected to Kitty Trouble matching kitty on Kitty to Firewire Backup 1, error -24201 (chunk checksum didn't match). - 2/14/2003 5:14:14 AM: Copying Pookie? Trouble matching Pookie to Firewire Backup 1, error -24201 (chunk checksum didn't match). 2/14/2003 5:23:00 AM: Execution incomplete. Total duration: 00:22:40 (00:22:24 idle/loading/preparing) So, do I have to do yet another complete backup--making the third I've done this week at something like 16 hours a pop? Evans Link to comment Share on other sites More sharing options...
CallMeDave Posted February 14, 2003 Report Share Posted February 14, 2003 Quote: Why would the large catalog be the problem? Possibly because you are running on hardware that is completely unsupported by the OS vendor? I think Processor Direct Slot G3 updates are cool, and they have a good history with OS 8 and 9. But reports of processor upgrades causing problems with Retrospect under OS X began to surface on this Forum as soon as the software was released. If you have to hack an installer to get it to accept your CPU then it shouldn't be a surprise when pushing limits results in errors. And Retrospect is quite sensitive to errors! Dave Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.