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 our tip contest and you could win a prize.
If you are like most administrators, you probably dutifully back up your Exchange databases each night and store the backup tapes in a secure location. That's great -- but those steps alone may not be enough to get you through a serious disaster. In this article, I explain three of the most important disaster recovery best practices for Microsoft Exchange.
Documentation
Regardless of your organization size or server complexity, it is critical to document as much information as possible about your server configuration -- and keep it up to date!
Let me give you a case in point: A few years ago, I had an Exchange server catch fire (yes, this actually happened). I smelled the smoke and was able to put the fire out quickly. The rest of my network was OK, but that server was trashed. I was then at the mercy of my insurance company and backup tape.
At the time, I didn't have a full server backup available; all I had were the Exchange databases. This wouldn't be such a big deal -- except, if you're restoring Exchange databases (not a full system backup) to a new server, the server has to pretty much mimic the old one. The server's name has to be an identical match of the old server's name. It also helps if the volumes are structured similarly to the way they were on the old server.
This is why documentation is so important. At a minimum, you should document:
- Your server's name
- IP configuration
- Disk configuration
- What each volume is used for
- Hardware specifications
That way, if you ever have to replace the server, it will be relatively easy to configure the new hardware in a similar manner to the old system.
Back up critical systems
Another thing you should do to prepare for a disaster is perform full system backups (including the System State) -- at least once a month -- of your most critical servers.
There are a couple of reasons for this. First, Exchange Server is dependent on Active Directory. I was fortunate in that a fire only destroyed one server. But imagine if all my servers had been destroyed. A backup of the Exchange databases wouldn't have done me much good without a functional Active Directory.
Ideally, you want to create full system backups of all your servers. But if operational requirements prevent this, make sure you at least get a monthly backup of:
- Your DNS server
- At least one domain controller in each domain (preferably the domain controller that holds the operations master roles for the domain)
- A global catalog server
If you are a small organization, and your AD configuration hardly ever changes, you might be wondering why the once-a-month requirement is so important. Windows considers AD-related backups out of date after 60 days. There is a way to recover AD information older than 60 days, but it involves manipulating various tombstone settings, and can be difficult to accomplish. It's easier to just make sure you have a current backup.
Test your backups
Perhaps the most commonly overlooked disaster recovery planning step is to test your backups periodically.
When I worked for the military, we ran Exchange Server 5.0. The information store on one of the mail servers contained corrupted data that nobody knew about. Eventually, the corruption spread and the server crashed.
We soon realized that we had been backing up corrupt data for weeks, and none of our backups were any good. Had we occasionally tested the backups, we would have found out we had a problem and could have taken steps to repair the information store before it crashed.
Exchange Server 2003 is much more resistant to data corruption than Exchange 5.0, but it is still extremely important to test your backups from time to time. You never know when you might have a bad tape or some other unforeseen problem.
It's better to discover that you have a backup problem while your servers are still functional than while trying to recover from a disaster.
Conclusion
Disaster recovery planning goes way beyond backing up your Exchange databases each night, and there's no such thing as over planning for it. Follow the three best practices I've outlined here, and you'll be well on your way to disaster preparedness. To delve even deeper, check out Microsoft's Exchange Server 2003 Disaster Recovery Operations Guide.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO 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, 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:
Learning Center: 20 tips in 20 minutes -- protecting and recovering Exchange 2003 data
Reference Center: Exchange backup and recovery tips and resources
