Restoring an Exchange Server Computer

Last month, I wrote about backing up your Exchange Server computer. I discussed client-based versus server-based backup; which files you back up; backup types and strategies; and online, offline, and third-party backup applications. This month, I'll describe the restore process. I'll present several recovery scenarios, give you some disaster-recovery tips, and talk about a Microsoft utility that can prevent Exchange Server from automatically deleting Exchange objects after the restore process. Let's get started.

Server Restore
Restores come in several flavors, depending on what's crashed and what type of backup you have (offline or online). You might encounter any of these situations:

I'll walk you through the third scenario. Assume that NT is functional, but the disk where the exchsrvr resides has failed. You have a single-site, single-server organization; you've disabled circular logging; and the transaction log files are on another hard disk that is still intact. After you've replaced the bad hard disk, you discover that the only backup tape you have is the Exchange online backup tape from yesterday. The backup type is normal (and you don't have a current NT backup tape of the entire server).

Your goal is to restore from the backup tape and then roll forward the transaction logs from yesterday's last backup to the time of the hard disk crash. Ideally, this procedure will rebuild the server up to the point of failure with almost no message loss. Here are the steps for restoring the Exchange Server system.

Disaster Recovery Tips
To improve your chances for a full recovery from a crash, you must store the Exchange database files on a different hard disk from the transaction logs. The Exchange Performance Optimizer places the transaction logs on the fastest hard disk it can find and, if possible, on a different partition from the .edb databases. However, this utility can't see physical partitions. Therefore, if you have two physical disks (and no disk striping) and the faster disk is split into two partitions (e.g., C and D), Performance Optimizer might place the .edb files on one of those partitions and the transaction logs on the other partition of the same physical disk and not place any files or logs on the other drive (E). This placement is undesirable, because both the databases and transaction logs are on the same spindle. If the disk crashes, you can restore only from the last backup and you lose all transactions between the last backup and when the crash occurred.

You can place these two files on different physical disks by rerunning Performance Optimizer and manually changing the paths, as you see in Screen 5, page 4, to store .edb files on a different disk. Then, if that disk crashes, you need only run the restore tapes and restore up to the last transactions recorded before the failure.

Here are some other disk administration tips:

Microsoft has provided its customers with information about recovering Exchange. Two excellent white papers are MS Exchange Disaster Recovery Part I and Part II in TechNet, February 1998. These papers are required reading for any backup operator.

Finally, don't forget that Microsoft has a GUI-based command scheduler that can perform offline backups automatically at specified times. Microsoft introduced this utility (WINAT) in the NT 3.51 resource kit. You need to create a batch file to shut down the Exchange Server services before the backup routine runs. Part I of the disaster recovery white paper describes this process in detail.

Another Backup Tool
Sometimes you might need to restore a server because of operator error instead of as a result of hardware failure. For example, if the administrator inadvertently deletes objects in the Recipients container, users can't log on to Exchange because they no longer have a mailbox. In this case, you can restore the server with the populated Recipients container from an earlier backup tape and then replicate this good information from the restored server back to all the other servers. Use the Authoritative Restore tool for this restore.

Authoritative Restore (AuthRest.exe) is on the Exchanger Server CD-ROM, and you use it when the restored server is the directory database of choice. For example, if you delete data by mistake, Exchange Server will replicate this information to other servers in the site. If you later perform a restore with a tape that includes the old mailboxes, the other servers will tell the restored server to delete those mailboxes. Authoritative Restore forces the new restored server to replicate its directory to all other servers in the organization. Be careful: Don't use this utility without an experienced Microsoft consultant on hand, because little documentation about its use is available.

Practice Makes Perfect
Question: What do you call an administrator who doesn't back up? Answer: Unemployed. You can see why you must faithfully follow a well-documented disaster-recovery strategy. Microsoft has made backing up easy with tons of information to guide you in implementing a plan. However, Microsoft can't make you back up—doing so is up to you.

I was quite concerned about doing my backup and restore. I performed a simulated crash by using the uninstall routine to remove Exchange Server from my PC. The thought crossed my mind more than once that I might permanently destroy what had taken me months to fine-tune. However, nothing is more crucial than going through a trial restore. Microsoft recommends doing a mock restore on a test system to obtain experience so you'll be prepared when the time arrives for the real thing. Although the process was intimidating, I feel more confident that I could restore Exchange Server in a production environment if I had to. And remember: You don't have to go it alone. If a production system goes down, call a Microsoft Exchange consultant to work with you.

The bottom line is, how valuable is your information? If losing data would cause you pain, then back it up.