Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2007-08-20

The following checklist helps you prepare for disaster recovery. For step-by-step procedures for backing up and restoring Microsoft Exchange Server 2007, see Disaster Recovery Procedures.

Checklist: Disaster Recovery Preparation

Prepared by:





Implement practices that minimize the effects of a disaster.

Consider implementing the following measures to help prevent or minimize the effects of a disaster:

  • Have your software and firmware updates available.

  • Have all software disks easily available.

  • Maintain hardware records.

  • Keep spare hardware available if possible.

  • Maintain software records.

  • Keep copies of all software needed for your server.

  • Document and test your recovery procedures.

  • Train your staff on disaster recovery procedures.

  • Perform disaster recovery simulation drills.

  • Make sure that your insurance policy is sufficient.

  • Consider using local continuous replication (LCR), cluster continuous replication (CCR) or single copy clusters (SCC) to protect your mailbox data. For more information about LCR, CCR, and SCC in Microsoft Exchange Server 2007, see High Availability Strategies.

  • Implement fault tolerance in your organization at the hardware or software level. Consider using methods such as RAID, multi-path hardware solutions, clustering, or data replication with LCR. For more information about achieving fault tolerance, see High Availability.

  • Make sure that you have sufficient hard disk capacity for your Exchange 2007 servers. You should have sufficient space on your hard disk to restore both the database and the log files of your largest database. For more information about disk capacity planning, see "Sizing Databases" in Planning for Mailbox Servers.

  • Put your transaction log files and database files on separate physical drives.

  • Implement practices to minimize Exchange database backup and restore times.

  • Create schedules for archiving your backup media.

  • Archive the backup media in a secure location, for example, a fire-proof safe or at another location (offsite storage).

  • Have a plan to monitor servers proactively. For more information about monitoring servers, see Quick Start for Exchange 2007 Management Pack for MOM 2005 SP1.

  • Monitor the health of the Exchange store. For example, monitor the event log for the occurrence of 1221 events to determine the amount of white space available in a database. If the available white space equals 30 percent of the size of the database, you might want to consider offline defragmentation of Exchange databases. Monitor your Event log for 1018 events that indicate when your disks might be starting to fail.

  • Verify the integrity of your backups; make sure that they occur without error.

  • Distribute your users across multiple mailbox stores.

  • Configure deleted item retention for your users.

  • Configure deleted mailbox retention at the mailbox level.


Establish a backup and restore strategy.

Choose a backup strategy that lets you meet your business requirements and service level agreements for variables such as allowed downtime, allowed recovery time, and data loss tolerance.

A backup strategy includes the following:

  • Choose your backup method, see Database Backup and Restore.

  • Choose backup hardware.

  • Choose backup application.

  • Identify what needs to be backed up. For details about what you need to protect, see What Needs to Be Protected in an Exchange Environment.

  • Choose a strategy for recovering from different service or server failures, such as:

    • How to recover from an entire mailbox server failure. For example, restore the server, rebuild the server, or use a stand-by recovery server.

    • A single or multiple database failures. For example, use a dial tone recovery to restore a single database. For more information about the dial tone recovery approach, see Dial Tone Recovery.

    • Client Access server failure. Do you rebuild the server quickly, or can you fail over to another Client Access server? For more information about recovering from a Client Access server failure, see How to Back Up and Recover a Client Access Server.

    • Hub Transport server failure Do you rebuild the server quickly, or can you fail over to another Hub Transport server?

      It is recommended that you never allow your Hub Transport server to be directly connected to the Internet.
    • Edge Server failure. Can you fail over to another Edge server, can you bypass the Edge server and have mail flow directly to the Hub server, or can you rebuild the server fast enough? For more information about recovering from an Edge Transport server failure, see Using Cloned Configuration Tasks for Edge Transport Server Disaster Recovery.

  • Determine a backup schedule for each category of data that you want to help protect and the frequency of backup types (normal, incremental, or differential) for each category. For more information to assist you in preparing backup schedules, see What Needs to Be Protected in an Exchange Environment.


Make sure that you help protect the data you need.

Identify the components that can be restored by replicating data from other sources (for example, data that is stored in Active Directory directory service), what components must be restored from backups (such as Exchange databases and transaction log files), and what data can be re-created (such as connector and server configuration).

The data that you can help to protect includes the following:

  • Microsoft Windows Server operating system data

  • Domain controller data

  • Exchange 2007 databases and transaction logs

  • Edge server configuration data

  • Hub server configuration data

  • Client Access server configuration data.

  • Certification authority (for servers running certification services)

  • Cluster configuration data (if you are using back-end clustering)

  • Individual mailboxes (optional)

  • Unique dynamic data   Preserve any other data stored on your servers that is specific to your organization and that would be difficult to re-create or restore. For example, this data might include custom scripts or Web forms for Internet Information Services (IIS).