Three Tips for disaster recovery of Exchange Server

If you are the same as most administrators, you may have to back up your Exchange database responsibly every night and store the backup records to a secure location. This is great-but taking these steps alone may not completely escape from a serious disaster. In this article, I will introduce the three most important and optimal methods for Microsoft Exchange disaster recovery.

Document

You don't have to consider the size of your company or the complexity of your servers, the most important thing is to record as much information as possible about your server configurations in the document-and keep it updated at all times.

Let me provide you with a proper example: A few years ago, the Exchange server I used caught fire (yes, it actually happened ). I smelled smoke, so I soon put out the fire. The rest of my network is good, but the server is a pile of garbage. At that time, I felt sorry for my insurance company and those backed up materials.

At that time, I was not able to use all the backups on the server; all I had was the Exchange database. However, this is not a big problem. If you restore the Exchange database (not all system backups) to the new server ), this server must be very similar to your original server-this is a big problem. The new server name must exactly match the old server name. Similarly, the volumes on the new server must be constructed in a similar way as those on the old server.

This is why the document is so important. Your document should contain at least the following:

• Your server name
• IP configuration
• Disk configuration
• Usage of each volume
• Hardware details

If you need to change the server, you can easily configure new hardware in a way similar to the old system.

Back up important systems

Another thing you need to prepare for a disaster is to back up all the system backups (including the system status) of your most important servers-at least once a month.

There are many reasons for doing so. First, Exchange server depends on the Active Directory. In that fire, I was lucky to lose only one server. But imagine what if all the servers are burned down? If there is no active directory, the backup of only one Exchange database will not bring me much benefit.

Ideally, you want to create all system backups for all your servers. However, if operational requirements prevent you from doing this, make sure that the backups you make every month include at least:

• Your DNS Server
• At least one domain controller exists in each domain (select the domain controller that assumes the operation master role of the domain)
• Global Database Directory server)

If your company is a small enterprise and your Active Directory configuration is almost unchanged, you may have to wonder why the requirement to back up once a month is so important. This is because the Windows operating system considers the backup related to the Active Directory for more than 60 days as expired. Although there is a technology to restore the Active Directory for more than 60 days, it involves operations on a variety of tombstone settings, and it is difficult to complete. So it is easier for you to have the correct backup.

Detect your backup files

It may seem like the most common disaster recovery plan step to regularly detect your backup files.

We use Exchange Server 5.0 when I work in the military. Information is stored in an email server, which contains corrupted data, but no one knows about this situation. Eventually, the damaged data spread, and the server was also destroyed.

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

Exchange Server 2003 has more and better functions than Exchange 5.0 to prevent data corruption, but it is critical to often detect your backup files. Because you cannot know when you will encounter damaged disks and other unpredictable problems.

It is much better to find that your backup file is faulty when your server is still running.

Conclusion

The importance of a disaster recovery plan is much greater than that of backing up your Exchange database every night. Nothing is more important than doing it. According to the three best methods I have just introduced, you will be well prepared for the disaster. If you want to study this issue more deeply, refer to Microsoft's article: Disaster Recovery guide for Exchange Server 2003.