Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2012-03-19
For many organizations, messaging services are mission-critical or business-critical. If the messaging system is not available, productivity can be lowered, and business and revenue opportunities can be lost. Even if e-mail is neither mission-critical nor business-critical to your organization, chances are that the loss of messaging services would create a substantial disruption to your organization.
All of the redundancy, security and fault tolerance in the world cannot help you when it comes to a damaged, corrupt, or lost database. Backing up the critical data in your Microsoft Exchange Server 2007 organization is a necessary operational task for all organizations.
As part of your disaster recovery planning, it is important that you understand how to correctly back up Exchange 2007, how to restore Exchange 2007, and how to repair corrupt databases when no backups are available. Disaster recovery planning is a complex process that relies on many decisions that you make regarding the planning for Exchange 2007. Generally, to start the planning process, you must first consider the following concepts that relate to Exchange 2007 disaster recovery:
Knowing what you may have to recover from
Considering your service level agreement requirements
Understanding the importance of deploying Exchange 2007 with disaster recovery in mind
Understanding how Exchange relies on the Active Directory directory service
Understanding Exchange database technology
Disaster recovery for Exchange 2007 is enhanced by or is also available as a service from Microsoft Exchange Hosted Services. Microsoft Exchange Hosted Services is a set of four distinct hosted services:
Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware
Hosted Archive, which helps them satisfy retention requirements for compliance
Hosted Encryption, which helps them encrypt data to preserve confidentiality
Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations
These services integrate with any on-premise Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Microsoft Exchange Hosted Services, see Microsoft Exchange Hosted Services.
Many types of failures and disasters may require that you repair or restore one or more parts of your messaging system. It is important that you have a strategy in place to recover from the following situations:
Lost mail item (permanently deleted mail)
Lost database or storage group
Lost server that is running Exchange 2007 (Exchange databases and transaction log files intact)
Lost server that is running Exchange 2007 (Exchange database and transaction log files also lost)
Lost computer in an Exchange 2007 Network Load Balancing cluster
Lost computer in an Exchange 2007 back-end Microsoft Windows Server failover cluster
Lost database or storage group for a Windows failover cluster
Lost entire Exchange 2007 back-end Windows Server failover cluster
Lost external services (including domain controller services, global catalog services, certificate services, DNS, etc.)
Lost site (including all Exchange servers and all servers that provide external services)
A company that does not backup enough data on the servers in their messaging organization has not carefully considered its backup strategy. For example, if your organization experiences a disaster, such as a lost mailbox server (including its Exchange databases and transaction log files), and only has backups of the Exchange databases and transaction log file basic server elements, you may be able to recover the Exchange 2007 database files and some Exchange configuration data. However, with such limited backups, you may not be able to recover all the data and information that existed on the original server. Data and information on the original server could include cluster configuration information, management scripts, or system management software that resided on the server before it was lost. We recommend that you document all configuration settings and changes you make to a server starting immediately after Setup is completed, so that you can manually redo them after a disaster.
Conversely, if you take time to backup everything in your Exchange 2007 organization, you will likely be able to restore completely all critical data and configuration settings. However, if you back up all the data in your organization, your backup and restore processes will be more complex, more time-consuming, and will require more tapes or disk space than if you did not back up all the data.
To determine exactly what data that you need to back up to successfully recover from a disaster, we recommend that you practice disaster recovery procedures in a test environment before you implement a backup strategy on your production servers. Additionally, after you have implemented a backup and recovery strategy, you should consider conducting test restore operations regularly to make sure that you will be able to recover from various disasters that may occur.
The data that you need to back up depends on the type of full server recovery strategy you select. A full server recovery is when a disaster damages one of your servers to a point where you must take steps to, at a minimum, rebuild or restore the operating system and Exchange installation. Additionally, you may have to restore other information such as Exchange databases. You can categorize full server recovery strategies as either a full computer backup and restore, or a clean operating system install and Exchange disaster recovery.
Each server recovery strategy has its own set of backup and restore procedures:
The full computer backup strategy must include the Exchange binaries. Restores require a System State restore, which should be performed using similar hardware.
The clean operating system installation method includes recovering Microsoft Windows by running Windows Setup, restoring a Windows backup set, and then running Exchange 2007 in Disaster Recovery mode to retain your Exchange configuration.
Exchange 2007 provides additional flexibility with regard to how you can recover mailboxes. This flexibility is made possible using features such as the recovery storage group. You can also help protect mailbox data on the client side with the Cached Exchange Mode feature of Microsoft Office Outlook 2007.
|Your ability to help your users protect their mailbox data is enhanced when your clients are using a client application that supports client-side caching.|
Consider implementing one or more of the following strategies to help you be prepared to recover individual mailboxes or individual items:
- Server-side deleted item retention In this method, you help protect mailboxes from accidental item deletion through the clients by saving deleted items before purging them from a mailbox. You can customize the deleted item retention period for your users. For information about the best practice of configuring deleted item retention periods, see Best Practices for Minimizing the Impact of a Disaster.
- Server-side reconnect of a deleted or orphaned mailbox In the case of deleted or orphaned mailboxes, you can reconnect them to a user account using the Exchange Management Console or by using the Exchange Management Shell. You can customize the time that deleted or orphaned mailboxes can be retained on the server. For information about the best practice of configuring mailbox retention periods, see Best Practices for Minimizing the Impact of a Disaster.
- Restoration of backups performed at the mailbox level In the case of a damaged mailbox, you can restore a user's individual mailbox from backup.
Note: If your users are using client-side caching of mailbox data such as Cached Exchange Mode, they should have a local copy of their mailbox data on their computer.
- Recovery storage group With the recovery storage group feature in Exchange 2007, you can mount a second copy of an Exchange mailbox database on the same server as the original database or on any other server that is running Exchange in the same Exchange administrative group. This action can be performed while the original database is still running and serving clients. With this capability, you can recover data from an older backup copy of the database without disturbing user access to current data. The recovery storage group can also be useful in various disaster recovery scenarios, most notably the messaging dial tone scenario.
- Third-party brick-level backups Some third-party backup tools let you back up and restore Exchange at the level of individual mailboxes.
- Alternate server method This method requires that you restore an entire database to a server outside of your production environment and that you extract the mailbox data that you want. Although this method is still valid, whenever possible, you should use the recovery storage group method.
When your Exchange data becomes damaged or is lost in a disaster, you must recover it from backup. There are several cases in which restoring from backup may be necessary, including:
- Corruption of one or more databases in a storage group In this case, the native single-database restore functionality of Exchange can usually be used to restore the damaged databases without interrupting access to other databases on the same server.
- Hardware failure that causes loss of access to transaction logs or databases In this case, you may have to recover all storage groups, including their associated logs and database files.
- Failure or damage to a mailbox or public folder server that requires the server to be rebuilt In this case, disaster recovery frequently requires rebuilding the underlying server and its operating system.
Individual databases in a storage group may be restored while all other databases remain online. This method is the preferred means of replacing a single failed database. When the database is remounted, pertinent transactions are automatically played back from the storage group's log files to bring the restored database back to the time of the disaster.
When you use Backup to restore Exchange databases, API calls are made to the Exchange Extensible Storage Engine (ESE) to restore Exchange database files and their associated log files. You can use Exchange database backups to restore one or more damaged mailbox stores or public folder stores. You can also use Exchange database backups to restore every mailbox and public folder on the server. In a disaster recovery scenario that involves rebuilding a server, use Backup to restore your Exchange databases after you run Exchange Setup and any Exchange service packs in Recover Server mode (assuming that Active Directory is still available).
Exchange 2007 supports hardware-based snapshots using the Volume Shadow Copy Service (VSS) implemented in Microsoft Windows Server 2003 and Windows Server 2008. Generally, it takes much less time to restore a backup that was taken using a hardware-based snapshot. Therefore, depending on the hardware and software that was used in the solution, restoring Exchange data from these types of backups may make it easier to meet the elements of your service level agreement (SLA) requirements that relate to the time that it takes to restore Exchange databases. Additionally, because larger databases can be restored more quickly, hardware-based snapshot restores can help you support larger database sizes and still let you meet your SLAs for restoring Exchange data.
To provide more flexibility when restoring mailboxes and mailbox stores, Exchange 2007 provides a feature named the recovery storage group. The recovery storage group is a specialized storage group that can exist alongside the regular storage groups in Exchange, even if the server already has the maximum number of regular storage groups. You can restore Exchange 2007 mailbox stores from any storage group in the Exchange organization.
After you restore a mailbox store to the recovery storage group, move the recovered mailbox data from the recovery storage group to the regular storage group. With this method, you can recover an entire mailbox store, which includes all the database information, including the log data, or just a single mailbox. Mailboxes in the recovery storage group are disconnected and are not accessible to users who have mail clients.
|You can only use the recovery storage group to recover mailbox stores, and not to recover public folder stores.|
The recovery storage group also makes it possible to offer dial-tone service quickly after a failure. This capability means that users can create and receive mail while their existing data is being restored. Frequently this approach is the fastest way to restore mail service to users. Because the volume of data generated by the users is likely to be less than the amount of data in the existing database, merging the dial-tone mail data into the original store after it is recovered is faster than moving the original database contents to a new store. When correctly used, the recovery storage group can be a powerful tool for reducing outage times.
Consider the following information before you perform specific recovery procedures in the Exchange 2007 organization:
Determine the time that is required to restore and play transaction log files. Performance in your environment may vary significantly from the average, and you should consider log replay in addition to restore time. If you perform weekly Normal backups and daily Incremental backups, you may have thousands of transaction log files that require replay after a restoration.
To minimize the time that it takes to recover an individual database, configure storage limits for the mailbox and public folder stores to constrain databases to a maximum size limit.
To back up Exchange data using the ESE streaming backup APIs or a VSS-based solution, the database must be online. You can still back up an offline database manually. However, in that event, manual checksum verification is required. In addition, performing an offline backup of Exchange involves an interruption of service to clients.
You can back up and restore databases in a storage group individually or simultaneously. As long as you do not exceed the data bandwidth capacity of your hard drives, controllers, and backup hardware, you can save time by simultaneously running multiple instances of Backup to back up or restore databases.
Windows Server Backup in Windows Server 2008 no longer supports streaming backups or restores. Unlike earlier versions of Windows Backup, you cannot make or restore streaming backups of Exchange by using Windows Server Backup. To back up and restore Exchange Server 2007 on Windows Server 2008 using the streaming backup APIs, you must use a third-party Exchange-aware application that uses the streaming backup APIs locally on the Exchange server to make a backup locally on the Exchange server. An application that uses a backup agent that runs locally on the Exchange server and streams the backup remotely to a backup application is considered a local backup.
Exchange 2007 Service Pack 3 (SP3) includes a new plug-in that enables you to make Volume Shadow Copy Service (VSS)-based backups of Exchange data using Windows Server Backup in Windows Server 2008. You can use Windows Server Backup to back up and restore your Exchange 2007 SP3 databases. A thorough understanding of what needs to be backed up, where to store backups, and how to restore backups is key to being an effective Exchange administrator. For more information about what needs to be backed up in Exchange 2007, see Using Windows Server Backup to Back Up and Restore Exchange Data.
You can use the topics in this area to protect your organization's data and plan for recovery in a variety of scenarios. The topics in this area include:
- Disaster Recovery Terminology
- Disaster Recovery Strategies
- Disaster Recovery Procedures
- Disaster Recovery Tools and Wizards
Note: These topics do not cover third-party backup and restore solutions. For information about how to use third-party software products for disaster recovery, see the third-party software documentation.