Three ways to Exchange server disaster recovery

If you're like most administrators, you might be responsible for backing up your Exchange database every night and storing your backup records in a secure location. This is great--but just taking these steps may not completely get you out of a serious disaster. In this article, I'll describe three of the most important and best ways to make a disaster recovery for Microsoft Exchange.

Document

You don't have to think about the size of your company or the complexity of the server, it's important to keep as many records in your document as possible about your server configuration-and keep it up-to-date.

Let me give you a proper example: a few years ago, I used an Exchange server that was on fire (yes, it really happened). I smelled smoke, so I quickly put out the fire. The rest of my network is fine, but that server is a pile of junk. At that time I really felt sorry for my insurance company and for the back-up information.

At that time, I had not been able to use all the backups about the server; All I had was the Exchange database. This is not a big problem, however, if you restore the Exchange database (not all system backups) to a new server, the server needs to be pretty close to your original server-that's the big problem. The name of the new server must exactly match the old server name. Similarly, volumes in the new server need to be constructed in a similar fashion to the volumes on the old server.

That's why documents are so important. You should include at least the following in your document:

Your server name

IP configuration

Disk Configuration

Purpose of each volume

Detailed instructions for hardware

If you need to change the server, doing so will make it easy to configure new hardware in a similar way to the old system.

Backup of important systems

Another thing that requires you to prepare for disaster is to have all of your system backups (including the system state) on your most important servers--at least once a month.

There are many reasons for doing so. First, the Exchange server is dependent on the Active Directory. I was very lucky in that fire and lost only one server. But imagine if all the servers were burned down? If there is no Active Directory, then a backup of only one Exchange database will not do me much good.

Ideally, you want to create all of your system backups for all of your servers. However, if there are operational requirements to prevent you from doing so, make sure that your monthly backups include at least:

Your DNS server

There is at least one domain controller in each domain (to select those domain controllers that assume the operations master role for that domain)

Domain-wide database directory server (global catalog server)

If your company is a small business and your Active Directory configuration is almost unchanged, you may wonder why it is so important to back up once a month. This is because the Windows operating system considers Active Directory-related backups to be out-of-date for more than 60 days. Although there is a technique for recovering more than 60 days of active catalogs, it involves operating on a variety of Tombstone (tombstone) settings and is difficult to complete. So it's easier for you to have the right backup.

Check your backup files

It may seem the most common disaster recovery plan step to periodically check your backup files.

When I was working in the army, we were using Exchange Server 5.0. Information is stored in a mail server that contains corrupted data, but no one knows about it. Eventually, the corrupted data spreads and the server is destroyed.

Soon we realized that the data we had been backing up once a week was already corrupted and none of our backup files were good. If we can detect these backup files from time to time, we may find these problems and be able to take steps to fix the storage medium of the information before it is completely destroyed.

Exchange Server 2003 has more and better protection against data corruption than Exchange 5.0, but it is critical to constantly detect your backup files. Because you don't know when you're going to run into damaged disks and other unpredictable problems.

It's much better to find your backup file problematic when your server is still working properly than you are trying to do for disaster recovery.

Conclusion

The importance of a disaster recovery plan goes far beyond the nightly backup of your Exchange database, and nothing is more important than the plan. Follow the three best methods I've just described, and you'll do well in preparing for the disaster. If you want to delve deeper into this issue, refer to Microsoft's article: Exchange Server 2003 Disaster Recovery Operations Guide.