Resources
title: Macintosh Internal Consistency Check and Configuration Errors created_at: 2012.02.13 updated_at: 2016.07.22 category: Resources platforms: Mac ---
Retrospect performs internal integrity checks during normal operation. Should one of these checks fail, Retrospect may report an "assert" or "chunk checksum" error, and halt operation. These errors indicate a problem. This note will help you figure out what to do if you encounter them.
A few definitions will help clarify the terminology:
Assert error: An "assert" error results in a dialog put up by Retrospect that halts operation. The dialog is the result of an internal consistency check in Retrospect that has failed. The only choice at this point is to quit Retrospect.
Chunk checksum error: Retrospect stores information in its backup set catalogs in "chunks" of data, each stored with a checksum, a number that helps verify data integrity. When Retrospect reads a chunk of data (for example when opening its configuration file, or reading file information out of the backup set catalog during the Matching step of a backup), it quickly verifies the data read from its own file and verifies that it matches the checksum originally stored with the data. If the data no longer matches the original checksum, it has become corrupt, and Retrospect reports a "chunk checksum" error. Typically this type of error occurs only with a specific media set, or when starting the Retrospect Engine, if your main configuration file has become corrupt.s
First, identify when the error occurs. The most important step in identifying the source of the problem is to identify what operation or action is happening when the error occurs. Below are general notes on the following operations:
Starting Retrospect Engine
Scanning for devices, or opening the Storage Devices window
Scanning a source volume in a backup or Copy operations
Starting a backup/Updating Catalog
Matching during a backup
Matching during a restore
Third-Party Software Conflicts
Operating System
If you get the error while the Retrospect Engine starts, your configuration file may be corrupt. Retrospect for Macintosh stores its configuration files in In the folder /Library/application support/Retrospect/
Stop the Retrospect Engine in System Preferences
Go to library/application support/Retrospect and remove the config80.dat and config80.bak files from the folder.
Start the Retrospect Engine from System Preferences. Retrospect will try to import your settings from the configs.xml file automatically
If you get the error while scanning for Devices, or when opening the Storage Devices window, the problem is likely device related. If this is the first time you have ever used Retrospect (in other words, if you just installed Retrospect and have never before scanned for devices successfully with Retrospect), please contact Retrospect Technical Support for assistance.
If Retrospect was working fine previously, and you just recently added a device or changed your configuration, this may be the cause of the problem. If you added a device, try removing it, to see if this makes the error go away. If this solves the problem, look up your new device in the Retrospect hardware database to see if there are any special notes about using that device with Retrospect. If you recently changed your configuration, verify that the changes you made were made correctly, and/or consider reversing the changes as a test, to see if that clears up the problem.
Check for loose cables, and/or incorrectly configured hardware. If you are using USB or IEEE 1394/FireWire devices, try removing one or more devices to simplify your bus, to see if this resolves the problem. If you are unable to determine the cause of the error, please contact Retrospect Technical Support for assistance.
While very rare, Retrospect can report one of these errors during scanning of a source volume. If this occurs, check the disk for corruption using the Disk Utility (OSX) disk checking utility, or another disk utility program. If the problem is repeatable, it may be caused by file or folder names or structures on the hard disk. You may be able to narrow down the problem by defining a favorite folders in Retrospect for each top level folder on the hard disk, and then scanning each one at a time, to determine the folder that causes the problem. Then you may be able to rename files or folders to avoid the problem.
Try going to library/application support/Retrospect and delete the rtrsec.dir folder. If a Retrospect file inside this folder is damaged, it can cause errors during a volume scan. The folder will be recreated during the next backup of each volume.
Try to disable Instant Scan on the source computer you are backing up when the error happens.
After scanning a source for backup, Retrospect matches the files found on that source with the contents of the media set you are backing up to. If a media set catalog file (typically stored on your hard disk) is corrupt, you may get an error during matching. If you do, verify that the error occurs at the same place by repeating the operation. If it does, likely the catalog file is corrupt. What happens if you try to back up the same source to a different media set? Is the problem isolated to one specific media set?
If this problem only happens when you use a specific media set, you will want to rebuild the media set catalog from the media, using Media Sets>Rebuild in Retrospect.
Right after scanning and matching during a backup, Retrospect writes the source "Snapshot" to the media set catalog. You may get an error at that time that includes "can’t save Snapshot". If you do, follow the tips in the note above for "Matching During a Backup."
If you get the error during restore preparation during the Matching phase, you likely have a corrupt catalog. Follow the tips in the note above for "Matching During a Backup."
If you encounter chronic chunk or catalog related problems, you will need to determine and eliminate the cause. The errors may include but are not limited to:
-24205 chunk file damaged during save
-24204 chunk file damaged during access
-24203 not a chunk file or badly damaged
-24202 chunk file map missing/damaged
-24201 chunk checksum didn’t match
-24160 catalog is invalid/damaged
-25040 catalog invalid/damaged
-25045 file is not a catalog
-25043 catalog version incorrect
Check your operations log inside Retrospect. The log will tell you what Retrospect is doing when these errors are reported, like “trouble scanning” or “trouble matching”.
First, determine if the errors are occurring with many catalog files, or only with one. If only with one, rebuild the catalog as noted above in "Matching During a Backup", or simply start a new media set. If the problems affect more than one media set, you may have a hardware or system configuration problem that is causing repeated corruption of the media set catalogs stored on your hard disk. We have seen these problems caused by specific failing hard disk.
Try running a disk check using Apple Disk Utility or another third party disk checking utility to verify that there are no bad blocks on the hard disk.
When doing a catalog rebuild, try storing your catalog files on a different hard disk or even a different folder on the same disk.
Try installing and using Retrospect on a different computer. If the problems go away, something was set up incorrectly in the original computer’s hardware or system software that caused regular corruption of data. Regardless of whether or not you are seeing problems with other applications or even with the Mac OS on the original computer, if moving Retrospect solves the problem, then something was not working properly on the original computer. You may not be able to determine the cause, given how complex computers are.
If you are unable to resolve the problems, please contact Retrospect Technical Support for further assistance. If the assert_log.utx file in library/application support/Retrospect has been updated recently, support will want to see that file along with a copy of your Operations_log.utx file.
Should you be unable to solve an internal consistency error problem on your own, Retrospect Technical Support will be glad to help you after a support incident is opened.
Last Update: July 22, 2016
