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!
I recently spent several weeks in a small country halfway around the world for a consulting project. Because it was so expensive to call home, my wife and I stayed in touch by e-mail.
But a few days after I left the U.S., our power failed in our business for just a second and left our computer network unable to access the Internet. I ended up troubleshooting on the phone from 12,000 miles away.
While all of my computers are connected to uninterruptible power supplies (UPSs), one of my UPSs didn't engage in time, and all the servers connected to that UPS went down. The servers were configured to automatically boot up when the power came back on, but my DNS server failed to reboot, resulting in the Internet access problem. Once the DNS server was manually booted, the problem was solved.
What would happen if the power failed in your company? You likely have all of your servers on UPSs, but a UPS can fail, especially if it's more than a couple of years old.
If you have a power failure and servers drop offline, fixing the problem might be as simple as booting up the servers when the power comes back on. But you also just might have your work cut out for you.
NTFS protects you
Years ago, I was an administrator of a NetWare network. Whenever the power failed, I almost always had to restore a backup for any server that went down.
Today, however, it's unlikely you would have to restore a backup if a file or print server went down. A lot of people don't realize it, but the NT file system (NTFS) contains safeguards against power failures. Whenever a file is created or modified, NTFS treats that operation as a transaction (meaning the operation is written to a transaction log before it's ever written to disk). In fact, any time you attempt to write a file to an NTFS, Windows performs the following steps:
- It records the meta data operations of the transaction to a log file that is cached in RAM.
- It records the actual meta data operation in RAM.
- It marks the transaction as committed within the cached log.
- The log is dumped to the hard disk.
- It writes the actual meta data operation to the hard disk.
(Note: Steps four and five don't always happen immediately.)
With these steps in place, if the power fails, Windows will automatically run a CHKDSK as part of the boot process. CHKDSK, among other things, looks at the log file and compares it to the hard disk. If any transactions exist in the log file but are missing from the hard disk or incomplete, Windows uses the information in the log file to reconstruct the transactions, bringing the hard disk up to date. The only data lost (usually very small) are transactions that have been written to a RAM cached log but have not been dumped to the log file on the hard disk.
It's relatively simple to bring a file server back online. Application servers can entail more work. I have booted an app server after a power failure and had to manually start a couple of services, but other than that, the server came up fine. More often, however, if the application is dependent on a database, the power failure corrupts the database.
Exchange Server is a good example of a database-dependent app server. It uses transaction logs in a manner similar to the NT file system. Even so, it's possible for a little bit of data to be lost during a power failure. If this happens, the database will be in an inconsistent state when the server reboots. You'd then have to use some of the built-in maintenance tools to bring the database back into a consistent state prior to being able to mount the database.
There are many types of database-dependent applications. Some have databases that use transaction logs, some don't. If you have a power failure on a database server that does not use transaction logs to protect the database, you might find yourself having to restore a backup.
http://www.brienposey.com>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. He has written for Microsoft and various TechTarget sites.