Exchange Server Disaster Recovery Plan & Tips: For Exchange Administrator

Regardless of the size of the Organization, Microsoft Exchange Server always host the database of the organization and user mailboxes. But what if, a disaster strikes the Server? No doubt, it will hamper the workflow of the whole organization. Therefore, all organization whether it is of small or large size has an Exchange Server disaster recovery plan. Everybody knows Exchange Server is always the main target of malicious software, system and get affected easily by system failure, hardware crash, etc. Keeping server in smooth working condition is always a tough task for the Exchange Administrator.

Therefore, Exchange Server disaster recovery plan comes into account. As normal functioning of Exchange Server is really important for an organization so, it is not surprising why companies or Exchange administrator have the main focus on good disaster recovery plans for the Exchange Server. Yes, it is true that no disaster recovery plan is perfect while using but it can minimize the actual impact of disasters on the organization’s database. Thus, this blog will let users know the almost perfect list containing Exchange Server Disaster Recovery plan and tips.

#1: Have Complete Knowledge of Exchange Database

There are some components through which Exchange Server Administrator are not very much familiar. Extensible Storage Engine (ESE) and files related to it are one of them. This might results in a number of misunderstandings and awful backup and restore practices. Thus, before making a recovery plan, an Exchange Administrator must have knowledge about the following:

Database: The Exchange database is comprised of two files i.e., EDB and STM files. Moreover, a database can be either store mailbox or public folder.

Transactions: Every time a data is written to the database, it is first written to the transaction log files. They are not much important for the performance but the essential component for the Exchange Server disaster recovery plan.

Consistent & Inconsistent Database: When all logs are committed successfully, header information of the database is flagged as consistent. If all logs are not successfully committed and the database is stopped before that, then the header of the database will be flagged as inconsistent.

#2: Make a Plan from Emails Point of View

The disaster recovery plan for emails is an integral part of any business plan, which is very beneficial for the whole organization. It is because if you miss a key dependency of the email system, your end users will immediately notice that the email is down. Moreover, in such case, there is a high possibility that Exchange Server is not the problem. It can be due to issue in DNS, network, Active Directory. Thus, it is important to always be prepared for all Exchange Server dependencies like Firewalls, Certification authorities (CA), Storage Area Network (SAN), Active Directory domain controllers, etc.

#3: Set up Server Hardware for Disaster Recovery

At the time of building an Exchange Server 2003, always try to configure the hardware and remove all single points of failure. Therefore, it is important to put some special consideration on the disk storage subsystem. It can be done in a proper way by choosing the proper RAID levels for all types of data. Some example of hardware that needs to be configured excessively is NIC, memory, RAID controllers, processors, etc.

#4: Use Inbuilt Exchange Server Features for Disaster Recovery

Microsoft Exchange Server has some inbuilt capabilities that let you have an advantage by minimizing the single points of failure and helpful in the process of disaster recovery. But these extra inbuilt capabilities are there in the Enterprise Edition of Exchange Server not in the Standard edition. However, if you enable all such features of Exchange feature, it would be considered as a best practice. Some of them are:

• Modify the Deleted Items/ Deleted Mailbox retention period according to your requirement.
• Add your transaction log files to a dedicated RAID 1 volume.
• Add each storage group on a dedicated RAID 5 or RAID 0+1 volume.
• Break the mailboxes of users and distribute them across multiple groups and mailbox stores.

Otherwise, you can choose some third-party tool also for Exchange Server Database Recovery instead of switching yourself to Enterprise edition.

#5: Imitating an Exchange Server Disaster

In most of the cases, the disaster recovery plans get failed because of improper testing of those processes. Thus, testing a recovery process at multiple stages is important to simulate the disaster. You need to prepare a documentation while testing containing details like time required to respond to a problem, check whether the procedure is right or not, where it is to be modified, etc. All such information will help in building a better Exchange Server disaster recovery plan and starts trusting the backup solutions more.

#6: Always Keep Yourself Familiar With New Ways

Building a perfect Exchange Server disaster recovery plan is never ending process.  Always become Continues task because the practices that are acceptable today may not be useful in future. Therefore, always keep on working on new, unique, and smart ways in order to make your plans better. Testing and monitoring your procedures on a regular basis is also one of the good practice.

Time to Sum Up

Always keeping one Exchange Server disaster recovery plan ready with you by considering all the major factors in mind is necessary. Having a checklist as discussed above will work as a safeguard and prevent data loss or any other bad impact on the Exchange Server. Thus, it is important to make a proper disaster recovery plan and keeps on mitigating the risk before it happens.