At the heart of Exchange lies the ability to retain
and allow access to vast amounts of data. Emails get populated in user's
mailboxes from both internal and external sources. Often, once an email
is received from someone, the only copy exists in the recipient's
mailbox. Inadvertently losing this data and not being able to recover it
can cause many problems.
It's difficult to
overstress the benefits of keeping backups of data for Exchange.
Traditionally, it was important to keep backups not only for data
recovery purposes, but also for the purpose of truncating transaction
logs. If you went multiple days without a backup, you risked the
possibility of transaction logs filling up the disk volume, which forced
Exchange to shut down the access to those databases.
However, backup technology
has evolved over the years and Exchange has kept pace with the changes
in backup technology. With technology like volume snapshots, it no
longer takes hours upon hours to back up databases in Exchange. In some
instances in Exchange Server 2010, it may be wise to eliminate backups
altogether and instead rely on data replication to meet your recovery
goals.
1. Develop an Effective Backup Strategy
At the cornerstone of
meeting your data recovery goals is the development of an effective
backup strategy. Without a backup strategy in place, you won't
understand what your backup requirements are or whether the backup tool
you use fits those requirements. It's also important to lay out your
recovery plans. When a disaster strikes and you have a limited time to
react, it's important to be able to pull out your recovery plan and
follow it with the assurance that it works.
To determine what your
backup requirements are, you must first understand why you are backing
up the data. Then you can determine what your goals are for recovery.
And finally, you can decide how often you want to perform backups.
1.1. Understand the Reasons for Backups
There are many reasons that an organization would want to perform backups, such as the following:
To have the ability to restore an entire server from scratch
To have the capability of restoring a failed or damaged database
To maintain a copy of the mailboxes of people who recently left the organization
To recover messages that a user has deleted
You will need to determine
which of these scenarios apply to your goals for recovery. For example,
you may not want the capability to restore an entire server from backup
if you are using DAGs for database availability. In this case, it might
not be a big deal to install a new Mailbox server with a different name
and enable a database copy on the server.
1.2. Determine Recoverability Goals
After you have an
understanding of why you want to perform backups, you can start
determining your goals for recovery. You will want to consider each
scenario for which that the backup is maintained and determine how long
you want to retain the data and how quickly you want to be able to
restore the data. You will use these metrics to determine what your
backup architecture will be. For example, you may decide to keep backups
on site instead of shipping them offsite in order to meet your data
recovery time objective.
Each scenario may have different recovery objectives. Table 1 demonstrates how recoverability goals can be different for each scenario.
Table 1. How Recoverability Goals Differ Between Scenarios
| Scenario | Data Retention Goal | Data Restoration Goal |
|---|
| Database becomes corrupt | Restored database must not be older than 1 day | Must have dial-tone service up within 1 hour and the database must be restored within 8 hours |
| Mailbox accidently deleted by administrator | Restored data must be less than 3 days old | Mailbox must be restored within 1 hour |
| User needs to recover a message that was deleted 30 days ago | Must be able to restore messages for up to 60 days | Message must be restored within 1 business day |
The key is to determine
the minimum and maximum lengths of time that backed up data must be kept
and select a backup methodology that allows you to restore the data
within your target restoration goal.
1.3. Decide on a Backup Schedule
When you know how
frequently you must back up the data, you can more easily determine what
your backup schedule should be. In keeping with the example described
in Table 1, you can see that restored databases must not be older than one day. This means that databases need to be backed up daily.
Also from Table 1,
you can see that the scenario requires you to be able to restore
messages for up to 60 days. Therefore, you know that you must be able to
keep 60 days of backups in order to meet this goal.
1.4. Consider Backup Alternatives in Exchange
It is worth mentioning
the new school of thought about backups in Exchange Server 2010. The
idea is that in some situations, backups may not need to be kept at all.
In fact, Microsoft decided to use this approach when deploying Exchange
Server 2010 internally and completely eliminated the cost of
maintaining data backups.
The idea of using
replication as an alternative to backups is met with mixed emotions by
different people. In many organizations, backups are performed in a
certain manner because that's the way they've always done it. In many
ways, this consideration is less of a technical consideration and more
of a psychological one. An environment where replication is used for
backups is not the right solution for everyone. However, the following
capabilities in Exchange Server 2010 fill in the gaps that backups have
traditionally been used to fill.
Server Failure
Add mailbox servers to a DAG and replicate copies of the databases to other servers.
Disk Failure
Place each database
and transaction log folder on the same physical disk. Add the mailbox
server to a DAG and ensure that at least three copies of the database
exist in the DAG.
Database Corruption
Enable transaction
log replay lag on the database copies in the DAG. This allows you to
recover the database without the transaction log that caused the
corruption.
Single Message Recovery
Exchange now has
single-item recovery built in. You just need to enable it and specify
how long you want to keep deleted messages for.
Mailbox Recovery
Exchange maintains a copy
of deleted mailboxes for 30 days by default. This time is adjustable if
you need to retain deleted mailboxes for longer periods of time.
Site Failure
Instead of using off-site backups, consider stretching your DAG across sites for site resiliency.
If you decide to
implement database replication as a replacement for traditional backups,
you should keep the following recommendations in mind:
Make sure that you have at least three copies of your databases replicated inside a DAG.
Implement
lagged database copies if you frequently experience logical corruption
of your mailboxes due to third-party applications.
Enable circular logging on your databases to ensure that transaction logs are truncated.
Make
sure that you implement your architecture in a way that allows you to
sleep peacefully at night. If you're constantly worried that you may
lose all three copies of the database, implement additional database
copies and maybe even place one or two of the copies in a different
site.
2.2. Perform Backups with the Windows Server Backup Tool
When the Windows Server Backup
Tool came out in Windows Server 2008, support for native Exchange
backups was removed. This capability is now back. Exchange Server 2010
installs a service called Microsoft Exchange Server Extension for
Windows Server Backup. This service provides Windows Server Backup with
the ability to make Volume Shadow Copy backups that are Exchange-aware.
Having this capability out of the box in Windows Server 2008 is a good
thing, but there are limitations to using Windows Server Backup for
Exchange backups:
Only full volumes can
be backed up. You cannot make a backup of the Exchange database and
transaction log files independently. Instead, the Exchange data is
backed up when you back up the volume that the data lives on. Because of
this, both the transaction logs and the database file for a given
mailbox server database need to be available in the same backup set in
order to restore the data.
Backups cannot be taken remotely. Backups must be initiated on the server either manually or via a scheduled task.
In order for transaction logs to be truncated, only full backups must be taken.
Single
databases cannot be restored. When you perform a restore, all the
databases that were backed up in the backup job are restored.
You can only back up active copies of the databases. Passive copies cannot be backed up with Windows Server Backup.
2.2.1. Install Windows Server Backup
Windows Server Backup exists
as an installable feature in Windows Server 2008. To install Windows
Server Backup and the command-line backup tools, run the following
command from a command prompt:
ServerManagerCmd -i Backup-Features
2.2. Perform a One-Time Manual Backup
To perform a one-time
backup manually with Windows Server Backup, use the following steps.
These steps may vary slightly if you are using Windows Server 2008 to
perform the backup.
Open Windows Server Backup by choosing Start => All Programs => Administrative Tools => Windows Server Backup.
In the Actions pane on the right, select the task Backup Once. This launches the Backup Once wizard.
On the Backup Options screen of the wizard, select Different Options and click the Next button.
On
the Select Backup Configuration screen, select Full Server to back up
the entire server or select Custom to choose which volumes you want to
back up.
In this example, we're only going to back up the volumes that contain Exchange databases. So choose Custom and click Next.
On
the Select Items For Backup screen, click the Add Items button to add a
volume to the backup list. This opens the Select Items dialog box.
In
the Select Items dialog box, check the box next to the volumes that
contain the databases that you want to back up. After you have chosen
your volumes, click OK to close the dialog box. Then click the Advanced
Settings button.
In
the Advanced Settings dialog box, select the VSS Settings tab. Choose
the option VSS Full Backup and click OK. Only full VSS backups are
supported when you are using the Windows Server Backup tool to back up
Exchange data.
Back in the Backup Once wizard, click Next.
On
the Specify Destination Type screen, select Local Drives to store the
backup on a local disk or select Remote Shared Folder to store the
backup on a network share.
In this example, we are going to store the backup on a local disk. Select Local Drives and click Next.
On
the Select Backup Destination screen, select the volume that you want
to store the backup on from the Backup Destination drop-down list. Only
volumes that have enough free space are displayed in the list.
Click Next to continue.
At the Confirmation screen, verify that the backup settings are accurate and click the Backup button to begin the backup.
While
the backup is running, you can safely close the Backup Once wizard by
clicking the Close button. This does not stop the backup.
When the backup is complete, click Close to close the Backup Once wizard if you haven't done so already.
2.3. Perform Automated Backups
In addition to
performing manual backups, you can set up scheduled backups that occur
in an automated fashion through Windows Server Backup. To set up
scheduled automated backups, use the following steps. These steps may
vary slightly if you are backing up a server that is using Windows
Server 2008 R2.
Open Windows Server Backup by choosing Start => All Programs => Administrative Tools => Windows Server Backup.
In the Actions pane on the right, select the task Backup Schedule. This launches the Backup Schedule wizard.
On the Getting Started screen of the wizard, click Next.
In
the Select Backup Configuration dialog box, select Full Server to back
up the entire server or select Custom to choose which volumes you want
to back up.
In this example, we're only going to back up the volumes that contain Exchange databases. So choose Custom and click Next.
On
the Select Backup Items screen, the list of volumes on the server is
presented. Check the box next to the volumes that contain the databases
that you want to back up. Then click Next to continue.
On
the Specify Backup Time screen, select Once A Day to back up Exchange
only one time each day. From the Select Time Of Day drop-down list,
select the time that you want to start the backups.
You also have the option of selecting More Than Once A Day if you want to back up Exchange multiple times throughout the day.
After you have selected your backup schedule, click Next.
On
the Select Destination Disk screen, place a check mark next to the
disks that you want to store your backups on. If you want to use disks
that are local to the server, click the Show All Available Disks button.
By default, only external disks are shown. Click Next to continue.
Note
that the disk you selected will be formatted and dedicated for storing
backups. If you see a dialog box that warns you about this, click the
Yes button to continue. You will lose the data on this disk if you click
Yes, so ensure that you really want to dedicate the disk for backups.
At
the Label Destination Disk screen, view the labels that are designated
for your backup disks. You can physically write this name on the disk or
record it on paper to ensure that you know what disk corresponds to
which label. Click Next to continue.
At
the Confirmation screen, verify that the backup settings are accurate
and click the Finish button to complete the process and prepare your
disks.
At
the Summary screen, view the results of the scheduled backup and click
Close to close the Backup Schedule wizard. If you previously had a
mounted volume and used that disk as your backup location, the volume
will no longer be available.
