Applies to: Exchange Server 2007 SP3, Exchange Server
2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2009-05-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
- 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
- Hosted Encryption, which helps them encrypt data to preserve
- 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.
What You May Have To Recover From
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 mailbox
- 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
- Lost computer in an Exchange 2007 back-end
Microsoft Windows Server failover cluster
- Lost database or storage group for a Windows failover
- 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.
Impact of the Full Server Recovery Strategy
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
Recovering Mailboxes and Individual Items
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
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.
Recovering Exchange Databases
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
- 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.
Recovering Exchange Databases from Exchange Streaming Backups Sets
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).
Recovering Exchange Databases By Using Hardware-Based Snapshot Backup Sets
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.
Recovery Storage Group Restore Considerations
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.
Database Recovery Considerations
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
- 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.
Database Backup and Restore on Windows Server 2008
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 2 (SP2) 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 SP2 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.
Disaster Recovery Topics
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:
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.