Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to SearchExchange.com. If we publish it, we'll send you a nifty thank you gift.
One of the most annoying aspects of disaster recovery is having a clueless manager constantly breaking your concentration by asking you when the mail server will be back up. You can avoid such annoyances to a certain degree by having a clear Service Level Agreement (SLA) in place that specifically defines how long Exchange Server can be down.
Many corporate SLAs dictate that any amount of downtime is unacceptable. Such companies often have high-budget Exchange Server clusters or another form of redundancy in place already, so this article doesn't really apply to them.
For the rest of us, Service Level Agreements might still sound like a pipe dream, because -- as we all know -- Exchange doesn't follow a timetable. If you've ever had to repair a corrupted Exchange database, you know that recovery is finished when it's good and ready. Exchange Server doesn't know or care about anyone's deadlines.
Even so, there are several things you can do to insure that Exchange is restored in a timely manner. More importantly, there are ways of keeping management out of your hair during the restoration process.
Establishing your recovery priorities
Step one is to get a clear answer from management in writing as to what is more important to it: restoring mail flow or restoring the previously existing data. Obviously, both are important, but you need to get a firm answer from management on which takes higher priority.
If management decides that top priority is mail flow restoration, congratulations. Your life just got a whole lot easier. All you really have to do is keep several blank hard drives waiting for the day when disaster strikes.
To get mail flowing quickly, you can just remove the hard drives that house the current Exchange databases and replace them with the blank hard drives (make sure your servers are structured in a way that allows you to do this without disrupting anything else). You can then perform a dial-tone restore, a special type of restoration that will get Exchange up and running quickly so you can focus your efforts on restoring the missing data.
If management decides that historical data recovery comes first, you need to find out how long management is willing to let the company go without mail flow while that data is being restored.
Management probably doesn't understand how long the Exchange database recovery process can really take. It would probably frown on mail flow being unavailable for days while a database is being restored or repaired. Communicate that possibility, and get a straight answer about how long the company can afford to go without mail flow during the restoration process. You can then determine if and when you need to revert to dial-tone recovery.
Structuring your Exchange databases
Regardless of your recovery priorities, you should take a look at how your Exchange Server databases are structured now, while your server is up and running without issue. I'm not talking about making sure that transaction logs are on a separate disk from the actual databases (although that is very important). I'm talking about evaluating the size of your Exchange databases.
Most administrators plan their Exchange databases based on the amount of disk space available. That's fine, assuming you're not worried about how long it takes to recover from a disaster. But imagine how long it would take to restore a 250 GB Exchange database.
It's better to split one massive database into a few smaller databases. You will still be backing up the same amount of data each night. But in an Exchange disaster recovery scenario, you'll have to restore a lot less data -- thus, quicker recovery. Also, since you won't have all your eggs in one basket, fewer users will be affected by a damaged Exchange database.
The best way to implement multiple databases is to place each database into a separate recovery storage group (RSG). (See Improve backup and recovery with multiple Exchange storage groups and Rethinking your Exchange storage groups.)
Since Exchange Server databases within the same RSG share a common set of transaction logs, if you can limit each storage group to a single database, you'll have a lot better chance of isolating any problems.
Also, placing each Exchange database on a separate physical disk (or at the very least, a separate volume) will reduce the chance of a hard disk failure bringing down all of your Exchange databases.
Conclusion
Unfortunately, there is no way to completely avoid an Exchange Server disaster without spending big bucks. But if high redundancy solutions aren't an option for you, at least there are some techniques you can use to reduce the amount of time it takes to recover -- and to keep management off of your back while you do.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Best Practices Checklist: Exchange Server disaster recovery planning
10 tips in 10 minutes: Fundamentals of Exchange backup and recovery
FAQ: Exchange Server backup and recovery
Exchange Server Backup and Recovery Learning Guide
