Testing your backups is an important part of protecting your data. But simply proving that you can restore a backup does not guarantee the integrity of the data.
File or folder level corruption can occur gradually, and by the time Windows produces an error message it is often too late to completely fix the problem. By the time Windows generates an error, you'll have been backing up corrupt data for some time.
The trick to protecting your data's integrity is to occasionally test the disk volume to make sure that corruption is not occurring. If you do detect some corruption, it may not be too bad, since you detected the problem early on, rather than waiting until the problem got to the point that it triggered a Windows error.
Oddly enough, the best tool for detecting file and folder corruption seems to be chkdsk. Several third-party disk utilities also do a good job of detecting file or folder problems, but many can only function outside of Windows.
While researching this article, I attempted to use Norton Disk Doctor (part of Symantec's Norton Systemworks) to check the integrity of a drive on one of my servers. But Windows would not allow Norton Disk Doctor to have direct control of the hard drive, meaning that a Norton Disk Doctor scan would require the machine to be shut down. Though a great tool, Norton Disk Doctor is impractical as a mechanism for occasionally scanning a volume for corruption, since shutting down servers is usually frowned upon.
There are three reasons why chkdsk is a good tool for detecting file and folder corruption:
There are three steps to configuring Windows to periodically run chkdsk against a volume. Step #1 is to open a Command Prompt window and run chkdsk manually, i.e., enter the chkdsk command followed by the drive letter that you want to scan… chkdsk C: ). The reason you should initially run chkdsk manually is because, depending on the size of the volume you're scanning, chkdsk could take hours (or even days) to complete. Chkdsk could also place an extra strain on a hard disk that is already performing at or near its maximum capacity. Because of these factors, I recommend running chkdsk manually the first time so you can see how it will affect your server.
Step #2 is to schedule chkdsk to run automatically. This is easier than it sounds. Microsoft provides the AT command as an interface to the Schedule service. This allows you to run a command at a specific date and time. Keep in mind that, for the AT command to work, the Schedule service must be running.
The full syntax of the AT command is as follows:
AT [\\computername] [ [id] [/DELETE] | /DELETE [/YES]]
AT [\\computername] time [/INTERACTIVE]
[ /EVERY:date[,...] | /NEXT:date[,...]] "command"
\\computername specifies a remote computer. Commands are scheduled on the
local computer if this parameter is omitted.
id is an identification number assigned to a scheduled
command.
/delete cancels a scheduled command. If id is omitted, all the
scheduled commands on the computer are canceled.
/yes used with cancel all jobs command when no further
confirmation is desired.
time specifies the time when command is to run.
/interactive allows the job to interact with the desktop of the user
who is logged on at the time the job runs.
/every:date[,...] runs the command on each specified day(s) of the week or
month. If date is omitted, the current day of the month
is assumed.
/next:date[,...] runs the specified command on the next occurrence of the
day (for example, next Thursday). If date is omitted, the
current day of the month is assumed.
"command" is the Windows NT command, or batch program to be run.
To see how this works, imagine that you wanted to run the CHKDSK C: command every Friday at 3:00 AM on a machine named Server1. To do so, you would use the following command: AT \\Server1 3:00 /Interactive /every:Friday chkdsk C:
Now that you know how to automate chkdsk, it's time for the Step #3: to make the results usable. Otherwise, chkdsk will simply run and then terminate, and you'll never know the outcome of the scan unless you happen to catch a glimpse of the screen at the end of the scan. I will show you how to export the scan results in my next article in this series.
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:
12 Jul 2007