Udostępnij za pośrednictwem

Understanding Backup, Restore and Disaster Recovery

  • Artykuł

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Microsoft Exchange Server 2010 features a new, unified platform for high availability and site resilience that makes deploying redundant, highly available mailbox databases quicker and easier. But even the most extreme forms of redundancy and fault tolerance can't protect you against every possible failure or disaster. Ensuring there's sufficient protection for the critical data in your Exchange organization is a necessary operational task for all organizations.

As part of your data protection planning, it's important that you understand the ways in which data can be protected, and to determine of those ways, which best suits your organization's needs. Data protection planning is a complex process that relies on many decisions that you make during the planning phase of your deployment.

Contents

Supported Backup Technologies

Server Recovery

Recovery Database

Database Portability

Dial Tone Portability

Exchange Native Data Protection

Supported Backup Technologies

Microsoft Exchange Server 2007 and Exchange Server 2003 include two different options for data backup and recovery: Extensible Storage Engine (ESE) streaming backup APIs and support for the Volume Shadow Copy Service (VSS) backup APIs. Exchange 2010 no longer supports the ESE streaming APIs for backup and restore of program files or data. Instead, Exchange 2010 supports only VSS-based backups.

Exchange 2010 includes a plug-in for Windows Server Backup that enables you to make VSS-based backups of Exchange data. You can use Windows Server Backup to back up and restore your Exchange databases. To back up and restore Exchange 2010, you must use an Exchange-aware application that supports the VSS writer for Exchange 2010, such as Windows Server Backup (with the VSS plug-in), Microsoft System Center Data Protection Manager, or a third-party Exchange-aware VSS-based application. Be aware of these limitations when using VSS for backup and restore of Exchange data:

  • The VSS plug-in that ships with Exchange 2010 can be used to back up volumes containing active mailbox database copies or standalone (non-replicated) mailbox databases only. It can't be used to back up volumes containing passive mailbox database copies. To back up passive mailbox database copies, you need either Microsoft System Center Data Protection Manager or a third-party Exchange-aware VSS-based application.

  • Passive mailbox database copies are backed up using a separate VSS writer in the Microsoft Exchange Replication service. The Microsoft Exchange Replication service VSS Writer doesn't support restores. Although you can back up a passive mailbox database copy using Microsoft System Center Data Protection Manager or a third-party Exchange-aware VSS-based application, you can't perform a VSS restore directly to a passive mailbox database copy. However, you can perform a VSS restore to an alternate location, suspend replication to the passive copy, and then copy the database and log files from the alternate location to the location of the passive database copy in the file system.

For detailed steps to back up and restore Exchange data using Windows Server Backup, see Using Windows Server Backup to Back Up and Restore Exchange Data.

Return to top

Server Recovery

Almost all of the configuration settings for Mailbox, Client Access, Hub Transport, and Unified Messaging server roles are stored in Active Directory. As with previous versions of Exchange, Exchange 2010 includes a Setup parameter for recovering lost servers. This parameter, /m:RecoverServer, is used to rebuild and re-create a lost server by using the settings and configuration information stored in Active Directory.

For detailed steps to perform a server recovery of a lost Exchange 2010 server, see Recover an Exchange Server. For detailed steps to recover a lost server that's a member of a database availability group, see Recover a Database Availability Group Member Server.

Return to top

Recovery Database

A recovery database is an Exchange 2010 feature that replaces the recovery storage group (RSG) found in previous versions of Exchange. A recovery database is a special kind of mailbox database that allows you to mount a restored mailbox database and extract data from the restored database as part of a recovery operation. You can use the Restore-Mailbox cmdlet to extract data from a recovery database. After extraction, the data can be exported to a folder or merged into an existing mailbox. Recovery databases enable you to recover data from a backup or copy of a database without disturbing user access to current data.

Before you can use a recovery database, there are certain requirements that must be met. A recovery database can be used for Exchange 2010 mailbox databases only. Mailbox databases from previous versions of Exchange aren't supported. In addition, the target mailbox used for data merges and extraction must be in the same Active Directory forest as the database mounted in the recovery database.

For more information, see Recovery Databases. For detailed steps to create a recovery database, see Create a Recovery Database. For detailed steps to use a recovery database, see Restore Data Using a Recovery Database.

Return to top

Database Portability

Database portability is a feature that enables an Exchange 2010 mailbox database to be moved to and mounted on any other Exchange 2010 Mailbox server in the same organization. By using database portability, reliability is improved by removing several error-prone, manual steps from the recovery processes. In addition, database portability reduces the overall recovery times for various failure scenarios.

For more information, see Database Portability. For detailed steps to use database portability, see Move a Mailbox Database Using Database Portability.

Return to top

Dial Tone Portability

Dial tone portability is a feature that provides a limited business continuity solution for failures that affect a mailbox database, a server, or an entire site. Dial tone portability enables a user to have a temporary mailbox for sending and receiving e-mail while the original mailbox is being restored or repaired. The temporary mailbox can be on the same Exchange 2010 Mailbox server or on any other Exchange 2010 Mailbox server in your organization. This allows an alternative server to host the mailboxes of users who were previously on a server that's no longer available. Clients that support Autodiscover, such as Microsoft Outlook 2010 or Office Outlook 2007, are automatically redirected to the new server without having to manually update the user's desktop profile. After the user's original mailbox data has been restored, an administrator can merge a user's recovered mailbox and the user's dial tone mailbox into a single, up-to-date mailbox.

The process for using dial tone portability is called a dial tone recovery. A dial tone recovery involves creating an empty database on a Mailbox server to replace a failed database. This empty database, referred to as a dial tone database, allows users to send and receive e-mail while the failed database is recovered. After the failed database is recovered, the dial done database and the recovered database are swapped, and then the data from the dial tone database is merged into the recovered database.

For more information, see Dial Tone Portability. For detailed steps to perform a dial tone recovery, see Perform a Dial Tone Recovery.

Return to top

Exchange Native Data Protection

Exchange 2010 includes several new features and core changes that, when deployed and configured correctly, can provide native data protection that eliminates the need to make traditional backups of your data. Using the high availability features built into Exchange 2010 to minimize downtime and data loss in the event of a disaster can also reduce the total cost of ownership of the messaging system. By combining these features with other built-in features, such as Legal Hold, organizations can reduce or eliminate their dependency on traditional point-in-time backups and reduce the associated costs.

In addition to determining whether Exchange 2010 enables you to move away from traditional point-in-time backups, we also recommend that you evaluate the cost of your current backup infrastructure. Consider the cost of end-user downtime and data loss when attempting to recover from a disaster using your existing backup infrastructure. Also, include hardware, installation, and license costs, as well as the management cost associated with recovering data and maintaining the backups. Depending on the requirements of your organization, it is quite likely that a pure Exchange 2010 environment with at least three mailbox database copies will provide lower total cost of ownership than one with backups.

Backups are typically used for the following scenarios, and there are Exchange 2010 features to meet each of these needs in an efficient and cost effective manner.

  • Disaster recovery   In the event of a hardware or software failure, multiple database copies in a database availability group (DAG) enable high availability with fast failover with no data loss. This eliminates the end-user downtime and resulting lost productivity that's a significant cost of recovering from a past point-in-time backup to disk or tape. DAGs can be extended to multiple sites and can provide resilience against datacenter failures.

  • Recovery of accidentally deleted items   Historically, in a situation where a user deleted items that later needed to be recovered, it involved finding the backup media on which the data that needed to be recovered was stored, and then somehow obtaining the desired items and providing them to the user. With the new Recoverable Items Folder in Exchange 2010 and the Hold Policy that can be applied to it, it's possible to retain all deleted and modified data for a specified period of time, so recovery of these items is easier and faster. This reduces the burden on Exchange administrators and the IT help desk by enabling end users to recover accidentally deleted items themselves, thereby reducing the complexity and administrative costs associated with single item recovery. For more information, see Messaging Policy and Compliance, Understanding Recoverable Items, and Understanding Retention Tags and Retention Policies.

  • Long-term data storage   Sometimes, backups also serve an archival purpose, and typically tape is used to preserve point-in-time snapshots of data for extended periods of time as governed by compliance requirements. The new archiving, multiple-mailbox search, and message retention features in Exchange 2010 provide a mechanism to efficiently preserve data in an end-user accessible manner for extended periods of time. This eliminates expensive restores from tape, and increases end-user productivity by enabling rich clients such as Microsoft Outlook and Outlook Web App access to older data. For more information see Understanding Personal Archives, Understanding Multi-Mailbox Search, and Understanding Retention Tags and Retention Policies.

  • Point-in-time database snapshot   If a past point-in-time copy of mailbox data is a requirement for your organization, Exchange provides the ability to create a lagged copy in a DAG environment. This can be useful in the rare event that there's a logical corruption that replicates across the databases in the DAG, resulting in a need to return to a previous point in time. It may also be useful if an administrator accidentally deletes mailboxes or user data. Recovery from a lagged copy can be faster than restoring from a backup because lagged copies don't require a time-consuming copy process from the backup server to the Exchange server. This can significantly lower total cost of ownership by reducing end-user downtime.

Log Truncation without Backups

One of the functions performed at the end of a successful full or incremental backup is the truncation of transaction log files that are no longer needed for database recovery. If backups are not being taken, then log truncation will not occur. To prevent a buildup of log files, you enable circular logging for your replicated databases. When you combine circular logging with continuous replication, you have a new type of circular logging called continuous replication circular logging (CRCL), which is different from ESE circular logging. Whereas ESE circular logging is performed and managed by the Microsoft Exchange Information Store service, CRCL is performed and managed by the Microsoft Exchange Replication Service. When enabled, ESE circular logging does not generate additional log files and instead overwrites the current log file when needed. However, in a continuous replication environment, log files are needed for log shipping and replay. As a result, when you enable CRCL, the current log file is not overwritten and closed log files are generated for the log shipping and replay process.

Specifically, the Microsoft Exchange Replication Service manages CRCL so that log continuity is maintained and logs are not deleted if they are still needed for replication. The Microsoft Exchange Replication Service and the Microsoft Exchange Information Store service communicate by using remote procedure calls (RPCs) regarding which log files can be deleted.

For truncation to occur on highly available (non-lagged) mailbox database copies, the answer must be "Yes" to the following questions:

  • Has the log file been backed up, or is CRCL enabled?

  • Is the log file below the checkpoint?

  • Do the other non-lagged copies of the database agree with deletion?

  • Has the log file been inspected by all lagged copies of the database?

For truncation to occur on lagged database copies, the answer must be "Yes" to the following questions:

  • Is the log file below the checkpoint?

  • Is the log file older than ReplayLagTime + TruncationLagTime?

  • Is the log file deleted on the active copy of the database?

For information about how to enable and disable circular logging, see Configure Mailbox Database Properties.

Considerations for Implementing Exchange Native Data Protection

There are technical reasons and several issues that you should consider before using the features built into Exchange 2010 as a replacement for traditional backups. The following list includes some of these considerations, although the list isn't exhaustive. There may also be special considerations or considerations unique to your organization. Consider the following issues:

  • How many copies of the database will be deployed? We strongly recommend deploying a minimum of three (non-lagged) copies of a mailbox database before eliminating traditional forms of protection for the database, such as RAID or traditional VSS-based backups.

  • Your recovery time objective and recovery point objective goals should be clearly defined, and you should establish that using a combined set of built-in features in lieu of traditional backups enables you to meet these goals.

  • You should determine how many copies of each database are needed to cover the various failure scenarios against which your system is designed to protect.

  • If you eliminate the use of a DAG or some of its members, does that capture sufficient costs to support a traditional backup solution? If so, does that solution improve your recovery time objective or recovery point objective service level agreements (SLAs)?

  • Can you afford to lose a point-in-time copy if the DAG member hosting the copy experiences a failure that affects the copy or the integrity of the copy?

  • Exchange 2010 allows you to deploy larger mailboxes, and the recommended maximum mailbox database size has been increased from 200 gigabytes (GB) in Exchange 2007 to 2 terabytes (when two or more highly available mailbox database copies are being used). Based on the larger mailboxes that most organizations are likely to deploy, what will your recovery point objective be if you have to replay a large number of log files when activating a database copy or a lagged database copy?

  • How will you detect and prevent logical corruption in an active database copy from replicating to the passive copies of the database? What is your recovery plan for this situation? How frequently has this scenario occurred in the past? If logical corruption occurs frequently in your organization, we recommend that you factor that scenario into your design by using one or more lagged copies, with a sufficient replay lag window to allow you to detect and act on logical corruption when it occurs, but before that corruption is replicated to other database copies.

Return to top

 © 2010 Microsoft Corporation. All rights reserved.