Testing your backups is a critical part of safeguarding your data. However, occasionally making sure that backups restore correctly does not do much to verify the integrity of your data.
The problem with testing your backups is that you could be backing up corrupted data and not even know it. I've seen many situations in which servers were backed up on a daily basis, and the backups were tested occasionally, but individual files or folders were corrupted even though they restored successfully. Unless someone opened one of these corrupted files and saw the results of the file corruption, the file corruption would often go undetected until it reached a severe level.
Unfortunately, there are no telltale signs that file or folder corruption is about to occur, and no obvious things to look for. Faulty hardware (particularly data cables that link drives to disk controllers) can cause file corruption. But file corruption can occur even with healthy hardware.
Hardware problems aside, file and folder corruption occur most often on RAID arrays. This is particularly true when an array is low on disk space. Granted, you should never let a disk array run out of disk space, but in the real world, things happen. I've seen file corruption occur on healthy arrays with plenty of disk space.
Detecting file and folder corruption
If corruption occurs within a file or folder, the problem will usually go unnoticed if you're simply backing up the data and testing the backup by restoring it elsewhere. If the files or folders that have been corrupted are used infrequently, you may never even notice the problem until Windows generates a warning message similar to the one shown below.
This warning message is generated automatically by Windows; I didn't perform any kind of action to make Windows display it. At first, it may seem nice of Windows to tell you about the corruption and to even tell you what to do about it. The problem is that by the time you see this warning, it may be too late: You might not be able to salvage your data.
While researching this article, I couldn't find any reliable information on the specific events or conditions that trigger the above warning message. But from personal experience, I can tell you that unless a catastrophe occurs that causes your data to become corrupted all at once, corruption begins long before this message is ever displayed. The message is typically only displayed when the corruption begins to affect file cluster linking information.
This is a big problem. . .for two reasons.
- Because the corruption likely began long before the message was displayed, if you see this message, you've probably been backing up corrupt data for some time. If you attempt to restore the files or folders mentioned in the error message, you'll likely be restoring corrupt data.
- The corruption probably cannot be fully repaired. The error message says that you can correct the problem by running CHKDSK. CHKDSK will usually correct linkage problems and other types of problems associated with the file allocation table, but it cannot recover corrupt data within the file itself.
Any type of file can become corrupted, but my point can best be illustrated with image files. The picture below was taken during a recent trip to Costa Rica. Windows reported the file as being corrupt, so I ran CHKDSK with the /F switch to correct the problem. CHKDSK made the file readable, but a few bytes of data within the image were lost. As you can see below, the lost data caused some distortion and some incorrect color in the photograph.
You can see a more extreme example in the next photo. This image was from the same trip and resided in the same directory as the one shown above. However, more data loss occurred with this corrupted image, which had been repaired by CHKDSK.
These images illustrate the point that data corruption can occur that is undetectable by simply testing your backups. I've seen similar types of corruption occur with Microsoft Office documents, Exchange Server databases, PDF files, etc.
I've shown you what happens when CHKDSK attempts to repair a corrupted file. What happens when it's an entire folder that's corrupted? CHKDSK will recover the corrupted folder, but may not be able to determine the folder's name or its location within the directory hierarchy. When this happens, CHKDSK renames the folder to FOUND, and appends a sequence number to the new folder name. The FOUND folders are placed in the volume's root directory, as shown in the following screen shot.
The contents of a recovered folder may or may not be intact, depending on the extent of the corruption. The only way to return the files to their rightful location is to look at the filenames and use that to figure out the folder's previous name and location. You can then rename the folder and move it to the correct location in the directory hierarchy.
Of course, this could be a problem for large organizations with thousands of folders on a volume. The administrator may lack familiarity with the folder in question.
I've shown you what can happen if disk corruption goes undetected. In Part 2, I'll show you some things you can do to improve your chances of detecting disk corruption before it gets out of hand.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for SearchWinComputing.com and other TechTarget sites.
More information on this topic:
