Applies to: Exchange Server 2013
Topic Last Modified: 2012-11-13
Microsoft Exchange Server 2013 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 which method 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
VSS writer changes in Exchange 2013
Unified contact store recovery
Exchange native data protection
Supported backup technologies
Exchange 2013 supports only Exchange-aware, Volume Shadow Copy Service (VSS)-based backups.
Exchange 2013 includes a plug-in for Windows Server Backup that enables you to make VSS-based backups of Exchange data. You can also use Windows Server Backup to back up and restore your Exchange databases. To back up and restore Exchange 2013, you must use an Exchange-aware application that supports the VSS writer for Exchange 2013, such as Windows Server Backup (with the VSS plug-in), Microsoft System Center 2012 - 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 2013 can be used to
back up volumes containing active mailbox database copies or
stand-alone (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 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 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 about how to back up and restore Exchange data using Windows Server Backup, see Using Windows Server Backup to Back Up and Restore Exchange Data.
VSS writer changes in Exchange 2013
Exchange 2013 introduces a significant change from the VSS writer architecture used in Exchange 2010 and Exchange 2007. These earlier versions of Exchange included two VSS writers: one inside the Microsoft Exchange Information Store service (store.exe) and one inside the Microsoft Exchange Replication service (msexchangerepl.exe). In Exchange, the VSS writer functionality previously found in the Microsoft Exchange Information Store service has been moved to the Microsoft Exchange Replication service. The new writer, which is named Microsoft Exchange Writer, is now used by Exchange-aware VSS-based applications to back up active and passive database copies, and to restore backed up database copies. Although the new writer runs in the Microsoft Exchange Replication service, it requires the Microsoft Exchange Information Store service to be running for the writer to be advertised. As a result, both services are required to back up or restore Exchange databases.
Server recovery
Almost all of the configuration settings for Mailbox and Client Access servers are stored in Active Directory. As with previous versions of Exchange, Exchange 2013 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 about how to perform a server recovery of a lost Exchange 2013 server, see Recover an Exchange Server. For detailed steps about how to recover a lost server that's a member of a database availability group (DAG), see Recover a Database Availability Group Member Server.
Unified contact store recovery
When Microsoft Lync Server 2013 is used in an Exchange 2013 environment, the user's Lync contact information is stored in a special contact folder in the user's mailbox. This is referred to as the unified contact store (UCS). If you restore a UCS-migrated mailbox, the instant messaging contact list for the target user may be affected. If the user was migrated after the last backup, restoring the mailbox will result in a complete loss of the user's contact list. In less severe cases, modifications to the contact list made by the user since the last backup will be lost. To mitigate this potential data loss, ensure the user is migrated back to the instant messaging server prior to restoring the mailbox.
Recovery database
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 New-MailboxRestoreRequest 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.
Using a recovery database for a Mailbox database from any previous version of Exchange isn'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 about how to create a recovery database, see Create a Recovery Database. For detailed steps about how to use a recovery database, see Restore Data Using a Recovery Database.
Exchange native data protection
Exchange 2013 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 2013 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 2013 enables you to move away from traditional point-in-time backups, we 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's quite likely that a pure Exchange 2013 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 2013 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 DAG
enable high availability with fast failover and 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 2013 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 and Data Loss
Prevention.
- 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
2013 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
Microsoft Office Outlook Web App access to older data. For more
information, see In-Place Archiving,
In-Place
eDiscovery, and In-Place Hold.
- 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 aren't being taken, log truncation won't 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 Extensible Storage Engine (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 doesn't 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 isn't 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 aren't deleted if they're 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 following must be true:
- The log file has been backed up, or CRCL is enabled.
- The log file is below the checkpoint.
- The other non-lagged copies of the database agree with
deletion.
- The log file has been inspected by all lagged copies of the
database.
For truncation to occur on lagged database copies, the following must be true:
- The log file is below the checkpoint.
- The log file is older than ReplayLagTime +
TruncationLagTime.
- The log file is deleted on the active copy of the database.
Considerations for implementing Exchange native data protection
There are several issues that you should consider before using the features built into Exchange 2013 as a replacement for traditional backups. There may also be considerations unique to your organization. Consider the following issues, and note that this isn't an exhaustive list:
- You should determine how many copies of the database need to 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 Redundant
Array of Independent Disks (RAID) or traditional VSS-based
backups.
- You should clearly define the recovery time objective and
recovery point objective goals, and you should establish that using
a combined set of built-in features in lieu of traditional backups
to enable 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.
- You should determine whether eliminating the use of a DAG or
some of its members captures sufficient costs to support a
traditional backup solution. If so, you should determine whether
that solution improves your recovery time objective or recovery
point objective service level agreements (SLAs).
- You should determine whether you can 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 2013 allows you to deploy much larger mailboxes, with
a recommended maximum mailbox database size of 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, you should determine your recovery point
objective if you have to replay a large number of log files when
activating a database copy or a lagged database copy.
- You should determine how you'll detect and prevent logical
corruption in an active database copy from replicating to the
passive copies of the database. This includes determining the
recovery plan for this situation and how frequently this scenario
has 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.