Exchange
Server 2010 changes the way you back up your Exchange mailbox
databases, removing the ESE streaming backup application programming
interface (API) and adding a Volume Shadow Copy Service (VSS)–based
plug-in for Windows
Server Backup. Now the only supported online backup method is using the
VSS plug-in for Windows Server Backup or an Exchange-aware VSS backup
solution.
Together with the
functionality that allows you to create copies of your databases on
multiple Exchange servers, Exchange high-availability features closely
link with disaster recovery.
1. Integrating High Availability and Disaster Recovery
You can integrate your high-availability deployment with disaster recovery, especially if you consider the Exchange Server 2010 high-availability features sufficient to satisfy your backup requirements.
1.1. The Link Between High Availability and Disaster Recovery
Using the
high-availability features built into Exchange 2010 such as database
availability groups (DAGs) allows you to minimize downtime and data
loss in the event of a disaster but can also reduce the total cost of
ownership of the messaging system. By combining these features with
other built-in features, such as Single
Item Recovery and Legal Hold, you are able to reduce or eliminate your
dependency on traditional point-in-time backups and reduce the
associated costs. You can spread database copies across multiple sites,
which allows you to address datacenter failures and maintain offsite
copies of a database.
1.2. High-Availability Provides Options Beyond Traditional Backup and Restore
Using DAGs to configure a lagged, or point-in-time, copy of a database allows you to delay committing changes
to the database for up to 14 days. Thus, you continuously maintain a
database at the states it went through during the previous day or week.
Therefore, if you have an issue with your current database, such as a
rogue administrator or a script changing many items at once, you can
revert to a lagged database copy and commit the transaction logs to a
specific time that you decide.
Using lagged database
copies, together with maintaining multiple database copies across more
sites, means that organizations can consider reducing the amount of
nightly backups. This is particularly true for medium-sized and large
organizations because they generally have a more complex backup and
restore infrastructure in place than small companies.
Evaluate the cost of your
current backup infrastructure, including hardware, installation, and
license costs, as well as the management cost associated with
recovering data and maintaining the backups. Depending on your
organization's backup requirements, a DAG environment together with
Exchange 2010 features such as Single Item Recovery may provide lower
total cost of ownership (TCO) than a traditional backup environment. If
you can reduce the backup-to-tape dramatically this also would save you
storage costs for the tapes for example.
1.3. Large Mailbox Considerations
Mailboxes that are more than
10 GB in size require a more flexible backup and restore method because
the amount of data they contain is dramatically more than those with
which Exchange Server administrators typically deal. The main concern
here is always about how long it takes to recover a database. Even
though the Exchange Server 2010 database structure handles large
mailboxes better than previous versions, you should be aware of the
additional data requirements for backup.
The amount of time it takes to
restore a backup during disaster recovery skyrockets when you have
large mailboxes. When you're planning to implement large mailboxes,
consider using multiple database copies and using the Single Item Recovery feature for Exchange Server 2010 to recover data. These features provide you with options to move away from traditional backups.
1.4. Backup and Restore Requirements in a Highly Available Deployment
Even though it may
appear that highly available deployments no longer require traditional
backups, they may still be needed in your environment. You may want to
use existing backup strategies that provide offsite data storage at secure locations, even if Exchange 2010 can provide additional offsite database copies. Sometimes backups also serve an archival purpose, and typically organizations use tape to preserve point-in-time data for extended periods, as mandated by compliance requirements.
Additionally, remember that
integrating high-availability features as an alternative to backups
only works for the mailbox database, not for other Exchange Server
resources, such as the Hub Transport configuration. You still may need
to consider using traditional backup for your Hub Transport servers.
2. Removal of ESE Streaming APIs for Backup and Restore
Previously, Exchange
Server used Extensible Storage Engine (ESE) streaming backup APIs as
well as the Volume Shadow-Copy Service (VSS) for Exchange-aware backup
and restore. Now, Exchange Server 2010 supports only VSS-based backups.
To back up and restore Exchange Server 2010, you must use an Exchange
Server–aware application that supports the VSS writer, such as Windows
Server Backup or Microsoft System Center Data Protection Manager or a
third-party, Exchange-aware, VSS-based application.
3. Storage Group Removal
One significant change in Exchange Server 2010 is the removal of storage
groups. In Exchange Server 2010, each database is associated with a
single log stream as represented by a series of 1-MB log files. Each
Mailbox server with an Enterprise Server license can host up to 100
active or mounted database copies, and with a Standard Server license
can host up to five active database copies. Passive database copies and
recovery databases are not included in this per-server limit as you are
able to create up to 257 databases per server.
4. Database Not Tied to a Specific Mailbox Server
Another significant change for Exchange Server 2010 is that databases are not tied to a specific Mailbox server. Database mobility expands the system's use of continuous
replication by replicating a database to multiple servers. This
provides better database protection and increases availability. If
failures occur, the other servers with database copies can mount the
database.
5. Using DAGs to Eliminate Traditional Point-in-Time Backups
Because you can have
multiple database copies hosted on multiple servers in a DAG, you can
also consider eliminating traditional point-in-time backups from your
organization and turning on circular logging on your databases. This
removes the transaction logs that are no longer required for any copies
of the database, so they do not accumulate. Normally, transaction log
files are removed when you do a full Exchange Server backup. Circular logging accomplishes the same task without doing a full backup.
