The following chapter contains some commonly asked troubleshooting questions and their solutions or workarounds. If problems still persist, contact Prosoft Engineering technical support.
Most cases of apparent freezing are actually slow reads due to disk problems. If Data Rescue runs into a disk area where the disk is having trouble reading, it may appear to freeze, but actually just be very slow. If you think it has frozen, make a note of what is being displayed on the progress display, for example, the block number, then check again in half an hour or so and see if it has advanced at all. If it progresses, it is probably just slow due to disk read problems. If you continue having difficulties, make sure cables connecting to the disk drives are properly seated and consider disconnecting or turning off any unnecessary devices connected to the computer.
If you have attached a drive with a damaged volume since you started Data Rescue, Data Rescue may not automatically notice it. Try the Expert > Refresh Volume List menu item. If the volume you are looking for still does not appear, it may be because Data Rescue is unable to find the correct name for it, in which case it may show some other name such as “unknown” for the volume name. Or it may be that Data Rescue can see the device, but is not able to recognize a volume structure on the device. If that is the case, you will need to choose the device name for scanning rather than the volume.
Finally, it could be possible that your drive is malfunctioning to the point where your computer is not able to talk to it at all, in which case even the device name will not appear. In this case, Data Rescue will not be able to scan your device. In this latter case, you might try some or all of the following things to see if your device can be made to appear: Double-check the drive cables and power source; remove/reattach the drive and/or power cycle it; power down and restart your computer. You can also double check that the problem isn’t with the Data Rescue software itself by looking for your volume/drive using Apple’s Disk Utility. If Disk Utility can see it, Data Rescue should be able to also; if Disk Utility can’t, then Data Rescue won’t be able to either.
Sometimes, your volume contains obsolete catalog entries. If Data Rescue finds two catalog entries with identical names, it first checks if the two entries refer to the same data. If so, then the items are called “true duplicates”, and only one of these will be retained, and the other automatically removed. If the two entries refer to different data, both of them are retained, even if they have identical names and appear to be in the same directory, because there is no way to know which one is the correct one. To find which is the correct entry, check dates and file contents.
There could be a few reasons for this, as explained below.
When you do a Deep scan, Data Rescue uses two different algorithms to locate files. These methods will often locate many of the same files twice – once under the Found Files folder and again under the Reconstructed Files folder. (Data Rescue does not currently have the capability to automatically cross correlate these sets of files, but may do so in a future version.) So if you elect to recover everything, it will often be the case that the total space required exceeds the original media size.
The second reason why the found files may total more than expected is the possibility of anomalously (and incorrectly) large files. In the course of scanning the media, Data Rescue will often come across bad files and catalog entries. Data Rescue is able to filter out the vast majority of these bad entries, but not all of them. Occasionally a few of these may show up in the recovery list with incorrect and large sizes. If you suspect this may be the case, you can easily find these large files by searching for files greater than a certain size using the Edit > Find menu item. A useful technique to eliminate these from the recovery is: first mark everything by clicking the checkbox for the top level folders, then search for and uncheck the large files which appear to be bogus.
A third possible reason is if the scanned drive makes heavy use of hard linked files, such as a Time Machine backup drive. Hard linked files are used by Time Machine to store many copies of the same file with the same content, without duplicating the contents. The current version of Data Rescue sees and recovers such files as individual files and does not share space among the files when recovering. For example, if there are 20 hard links to a 1MB file on the original disk, and you recover all 20 links, the recovered files will each take 1MB, or a total of 20MB. A future version of Data Rescue may alter this behavior. Until then, the best approach for this case is to select a single set of files to recover, such as the latest Time Machine backup folders rather than attempting to recover everything.
After scanning a large drive, there may be hundreds of thousands or millions of files and folders to deal with. When you click on a mark checkbox in the recovery list to mark or unmark files for recovery, especially the top-level folders, Data Rescue has to walk recursively down through most of these items to individually mark or unmark them. The time this takes is proportional to the number of found files.
With RAID, several component drives are set up to act logically as if they were a single composite drive. If your RAID drives or file system is in good enough shape that the system can still make them appear as a single logical drive, then Data Rescue should be able to scan that composite drive and recover files from it.
If the situation is such that the system cannot present the component drives as a single composite drive, then the answer depends on what kind of RAID your drives are set up to do. If the drives are set up to do mirroring (i.e. each file is stored completely on each mirror drive), then Data Rescue should be able to a Deep scan any of these component drives and recover files.
If the RAID is configured using Apple’s software RAID system, you may enable Expert features and use the Add RAID Set feature to help simulate and scan the RAID. If the composite RAID device is visible without adding a RAID Set, it is almost always better to scan that than to create a RAID Set and scan it.
The answer to this question depends on whether you’re talking about files recovered from under the Reconstructed Files or Found Files Folder.
Files recovered by catalog (i.e. from the Found Files folder)
It’s normal for a small percentage of recovered catalog files to be bad. But if you have checked a number of them and none of them are good, then chances are that they were recovered with the wrong Allocation Block Layout setting. Pick out a few files to use as test files, and go back and select a different Allocation Block Layout choice and recover a few files. If you find an ABL setting that gives good results on those files, re-do your big recovery with that setting.
Files recovered by content (i.e. from the Reconstructed Files folder)
It’s also normal for a small percentage of these files to be bad. If the original file was fragmented (not stored on disk in consecutive blocks), then it can not be properly recovered by content. In most normal situations, most files on a user’s disk will not be fragmented. Typical fragmentation rates for files tend to be just a few percent. Note: The ABL setting plays no role in recovering files under the Reconstructed Files folder.
In OS X, when a file is deleted, for example by dragging it to the trash and emptying the trash, the file’s name and folder information is usually erased by the system, and is therefore irretrievably lost. However in most cases, the most important part of the file – its contents – are still present on the disk. Finding the file by its contents alone is in general a difficult task, requiring algorithms to recognize those contents among all the billions of bytes of data on the disk. The Deleted File scan will list over 150 major file types it detects based on its file patterns.
In generic technical terms, Data Rescue’s content scan is potentially suitable for any file type that consists of a single fork. For files that have both a data and a resource fork, the forks may be recoverable separately by content scan, but Data Rescue has no means to connect the two pieces back together. Some “files” are in reality a collection of separate files which the Finder treats like a single file. This is called a “bundle”. The individual components of a bundle may be recoverable by content scan, but again Data Rescue has no automated way to associate these components back together into a bundle.
An additional requirement for a successful recovery by content is that the file’s data not be fragmented. In other words, it must be stored from beginning to end in consecutive media locations. Fortunately, most files get stored on disk that way. OS X tries to store files in a non-fragmented way when it can. Still it is typical for a small percentage of files to be fragmented, and these will not recover properly when found by content.
Important: Do not mistakenly use a defragmentation utility (or any other program which will alter your disk) after losing your files, and prior to scanning with Data Rescue. Doing so will only make it less likely that you will be able recover your files.
Note: The above limitations apply only to the files found by content. For files that are found by their catalog entries, the original bundles and forks may be properly recovered, and fragmentation is not an issue.
The actual list of file types recoverable by content can be seen from within Data Rescue by going to the Data Rescue Preferences menu and browsing through the File Modules tree. We expect to be adding to this list on an ongoing basis. For a recent list of filetypes recoverable by content, see the Release Notes file that came with your Data Rescue distribution.
For any file types not supported by default, Data Rescue’s FileIQ feature will allow you to analyze sample files and possibly generate a file module to help detect the files you are looking for.