6.7 Best practice 7: Develop an Exchange disaster-recovery plan

6.7 Best practice #7: Develop an Exchange disaster-recovery plan

A solid backup plan should be in place when moving from a development or test environment to a production one. In the same way as you would never deploy untested software, the production phase of a project should never be entered into without a solid backup and restore plan. Best practices for Exchange deployments mandate the development of a backup plan as one of the essential steps in the design of a Microsoft Exchange infrastructure. In addition to protecting data as thoroughly as possible, the backup plan must reflect organizational requirements. Some of these requirements can be a driving factor in the hardware solution design. In the course of developing a backup plan, a series of questions should be addressed:

1. How often should the backups be performed?

2. What information should be backed up?

3. Which medium will be used (tape, disk, or BCV)?

4. What level of automation is required (unattended)?

5. How can problems trapping, reporting, and resolution be ensured?

6. What should the retention, rotation, and archival policy be?

7. In case of failure, how long will the restore operation take?

8. Is there a mechanism that makes sure the backups are good?

9. How are the responsibilities defined to ensure that the backup operations are running smoothly and according to plan?

10. Are all the procedures documented thoroughly in such a manner that any member of the technical staff (including temporary staff ) is able to perform backup and restore operations should the need arise?

These questions are just samples that may or may not apply to your environment. However, I strongly encourage you to consider them during the planning and design phases for each significant Exchange disaster recovery planning project. Any plan should also include and comprehend the entire system, not just Exchange. While you as an Exchange system manager may not have ultimate responsibility or accountability for all aspects of the system recovery (such as the Active Directory or Windows Server), your plan needs to comprehend the complete system. For Exchange 2000/2003, this includes Windows and Exchange, but must also look at other components such as Internet Information Server (IIS) and third-party components as well. The disaster-recovery plan must also consider each possible disaster scenario from the most minor incident (individual item recovery such as a message) to the most catastrophic event (such as fire, flood, theft, malicious activity, and so forth). The plan must address backup procedures and methods, archiving, tape management, rotation, personnel training requirements, and any resource and staffing requirements. Once the plan has been developed, it must be thoroughly tested to ensure that the methods and procedures are valid for your environment. Don’t rely on common MIS-generic disaster-recovery planning for Exchange. Exchange is a specialized application that requires individual attention and a separate plan. The care that you take in developing and validating your disaster recovery plan for Exchange will have a direct correlation to how well the plan is executed and the level of availability you are able to achieve for your Exchange deployment.