Please let us know how useful you find this tip by rating it below. Do you have a useful Windows tip, timesaver...
or workaround to share? Submit it to our tip contest and you could win a prize!
It's been said that there are two types of hard drives: those that have failed and those that will. Sadly, this statement is absolutely true. Because hard drives contain lots of moving parts, they are more prone to wear and tear than just about any other part in your computer.
So, what do you do when a hard drive fails? If the drive is a part of a mirror set, a stripe set with parity or a mirrored stripe set, then you would simply replace the drive, and the lost data automatically regenerates onto the new drive.
But what if the failed drive is just an ordinary IDE interface that does not participate in a fault-tolerant set?
The ideal solution is to replace the failed drive and then restore your backup. Unfortunately, it has been my experience that many times a backup does not exist or is outdated, or it does not include everything that needs to be restored. If you do happen to have a backup available, you should replace the failed drive and restore your backup.
Backup is nonexistent -- what now?
If there is no backup, then your next course of action will depend on the nature of the computer containing the drive.
If the machine containing the drive is a workstation on a Windows domain, the failed drive theoretically shouldn't be a problem because users working in a Windows domain generally save their data to a network server rather than to the local hard drive. In that case, the local hard drive should only contain the Windows operating systems and the user's applications. You should be able to replace the hard drive and then either use a Remote Installation Server to reconfigure the workstation or manually reload Windows and any necessary applications.
Remove the disk and connect to another system. If the hard disk does contain important data, you should shut down the machine and remove the failed hard disk. Then connect the failed hard disk to another system as a slave drive.
There are a couple of reasons for doing this. First, you want to avoid working off of the failed hard drive if at all possible. As you attempt to boot the system, Windows may attempt to write temporary files to the hard disk. Any time that files are written to the disk, there is a chance that otherwise recoverable data may be overwritten. Therefore, I prefer to move the failed disk to a different system, and let that system boot off of its own hard disk rather than try to boot off of the failed disk.
The other reason why it's important to move the failed disk to another computer is because sometimes the hard disk may be perfectly functional. I have been in situations where I thought the hard drive had failed, but in reality, it was the computer's hard disk controller that had the problem.
When you move the hard disk to a different computer, you are attaching it to a known good disk controller. If the other machine's disk controller was the problem, then you should now be able to access all of the data on the hard drive without risking corruption caused by a faulty controller.
Make a backup of the failed hard disk. Yes, you read correctly. If you move the failed hard disk to another computer and the hard disk still seems corrupt, the first thing you should do is make a backup of the failed hard disk. While it's true that the majority of the files on the disk may be corrupt, there is a good chance that at least some of the files are still valid. You don't want to risk losing even more files than you already have, so back up the disk before the corruption spreads and before you attempt any sort of recovery. (Remember that sometimes disk recovery products can make the problem worse.)
Try to recover the data. Once you have backed up the bad hard disk, the next step is to try to recover the data. I personally like using Norton Utilities for data recovery, but there are a lot of data recovery programs that are just as good.
Sometimes one of the motors will fail on a hard drive. When this happens, the data is almost always still intact, but the computer is physically unable to access the data. When a motor goes out, usually your only option is to ship the drive off to a data recovery lab. Doing so can be expensive, but it's pretty much your only option if you want to recover the lost data.
As you can see, there are a lot of different ways a hard drive can fail. Since a failure can occur at any time, I recommend having fault-tolerant devices in place -- or at least having a current backup.
Bottom line: It's much easier to restore data from a backup than it is to recover it.
10 tips in 10 minutes: Disaster Recovery
Tip 1: Automated System Recovery remedies corrupted registry
Tip 2: Ultimate boot CD packs in recovery, repair utilities
Tip 3: Disk imaging for disaster recovery
Tip 4: Recovery programs fix OS mistakes
Tip 5: WinXP and Windows Server 2003 volume shadow copy service
Tip 6: Restore and recover with Windows 2000
Tip 7: Disaster recovery for SBS
Tip 8: Best Practices: Desktop disaster recovery
Tip 9: Bare metal restore via Automated System Recovery
Tip 10: What to do when your hard drive fails
The top 10 tips of 2005
Tip #1: How to change the Windows XP Product Activation Key Code
Tip #2: Create a bootable USB flash drive -- in a flash!
Tip #3: Create a bootable Windows Server 2003 CD
Tip #4: 8 common causes for 'delayed write failed' errors
Tip #5: Ultimate boot CD packs in recovery, repair utilities
Tip #6: Install Windows Server 2003 silently
Tip #7: Uninstall 'stubborn' programs
Tip #8: What to do when your hard drive fails
Tip #9: Windows XP and Windows Server 2003 volume shadow copy service
Tip #10: 'Unlocker' reveals processes that lock files
Editor's Note: You can receive similar hardware tips twice weekly by subscribing to our Windows Systems and Storage newsletter. Sign up now!
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as the chief information officer for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies.