Using Backup to Back Up and Restore Exchange Data

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

This topic explains how to use the Backup tool (NTBackup.exe), which is the backup application included in Windows Server 2003. You can use Backup to back up and restore your Microsoft Exchange Server 2007 organization. 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 What Needs to Be Protected in an Exchange Environment.

Backup is automatically modified to support Exchange when you install the Exchange management tools on a computer. Backup uses the legacy streaming APIs to perform mailbox and public folder database backup and restore. Backup has Volume Shadow Copy Service (VSS) capability for file-level backups, but it does not perform Exchange-aware VSS backups. (It does not work with the Exchange VSS Writers.) We do not recommend the use of Backup as a VSS-based backup solution for Exchange databases because those backups can only be taken at the file system level.

You can use Backup to back up and restore the following items on an Exchange server:

• Entire directories   For example, the Unified Messaging (UM) prompts directory.

• Selected files   For example, the .xml files with user-modified settings stored in the \bin folder.

• System State data   For example, the Windows Server 2003 operating system registry information.

• Exchange mailbox databases   One database or groups of databases.

• Exchange public folder databases   The public folder database on any server.

• Entire storage groups   Storage groups, including all the log files and database files.

• Remote data   Information from other servers or workstations over the network.

It is a best practice to perform backup and restore procedures in a test environment before you back up or restore your organization's production servers.

Exchange Backups and Continuous Replication

One of the benefits of using local continuous replication (LCR) or cluster continuous replication (CCR) is the ability to offload VSS-based backups from the active storage groups to the passive storage groups.

Exchange-aware VSS backups are supported for both the active and passive storage groups and databases. The passive copy backup support is only for VSS, and it is implemented by the Exchange Replica VSS Writer that is part of the Microsoft Exchange Replication service. Streaming backups are only supported from active storage groups. You cannot use streaming backup APIs to back up the database on passive storage groups.

Log Truncation

A common task during Exchange-aware backups is the truncation of transaction log files after the backup has completed successfully. One nuance of taking a backup of a passive storage group is that Exchange-aware backups modify the header of the database. For example, the backup process adds information about the time of the last backup of the database. VSS backups are made possible by the Exchange Replica VSS Writer that is built into the Microsoft Exchange Replication service. Although the Microsoft Exchange Replication service can replay log files into its copy of each database, it cannot independently modify its copy of the database because that would produce divergence. Therefore, it cannot modify the header of its database copy.

As a result, in Exchange 2007, the Microsoft Exchange Replication service coordinates its backups with the Microsoft Exchange Information Store service. As soon as you start a backup of a passive storage group, the Microsoft Exchange Replication service contacts the Microsoft Exchange Information Store service that controls the active group and tells it that a backup is about to start. This is done to prevent the same storage group on both the active and the passive nodes from being backed up simultaneously. After the backup is finished, the Microsoft Exchange Replication service contacts the Microsoft Exchange Information Store service and lets it know that the backup completed.

The database header modifications resulting from the backup are then made by the Microsoft Exchange Information Store service on the active storage group. This action generates a log record, which through continuous replication is copied to the passive node. When it is replayed, the database header on the passive node is then updated. This approach is more complex than traditional backups, and it has some interesting side effects. For example, if you back up a passive storage group and then immediately after the backup has finished, you look at the database header on the passive node, it will not reflect the backup. The database header on the active side will however reflect it. Thus, if you are backing up databases in a continuous replication environment, looking at the database on the active node is the most accurate way to determine the time of the last backup. Another side effect is that, if the Microsoft Exchange Information Store service is not running, you cannot make backups from the passive node. Running the Microsoft Exchange Information Store service is required so that backups can be coordinated and the database header can be updated.

With log files being copied and required by the Microsoft Exchange Replication service, it becomes more complicated when removing them. Currently, the conventional way to remove log files is to run a backup. Backup runs, and when it completes successfully, it deletes the logs you no longer need. The introduction of continuous replication changes the definition of need because now it takes into account the state of replication. If a log file has not been copied, it is still needed (even though the Microsoft Exchange Information Store service might not need it). As a result, a log file is not deleted until:

• It is not needed for failure recovery.

• It has been replayed on the passive node.

• It has been backed up.

To coordinate this, whenever the Microsoft Exchange Replication service finishes a replay, it contacts the Microsoft Exchange Information Store service and says that it replayed storage group X up to Y generation number. At that point, the Microsoft Exchange Information Store service knows that log files up to that generation number are no longer needed by the Microsoft Exchange Replication service. It can then analyze the state of the last backup and failure recovery, and it can work out which log files are no longer needed on the active node. On the passive node, things are even simpler. The passive node can analyze its own log files and determine which ones are needed for recovery, and which ones are needed for backup.

Changes for Streaming Backups in Exchange 2007 SP1

As part of the Microsoft continuing security initiatives, Microsoft Exchange Server 2007 Service Pack 1 (SP1) introduces a behavior change designed to reduce the attack surface of the system. This change directly affects remote streaming backups on Windows Server 2003.

The release to manufacturing (RTM) version of Exchange Server 2007 has remote streaming backup enabled by default. This default configuration is less secure because it allows anyone in the domain with sufficient backup rights to back up a server that is running Exchange. Moreover, data that is backed up remotely is not encrypted, and the backup is often performed over a public (client-accessible) network.

To adhere to the Microsoft Secure by Default initiative, the remote streaming functionality disabled (server-wide) in Exchange 2007 SP1 is disabled by default. A manual override in the form of the following registry value must be enabled to restore this functionality:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Name: Enable Remote Streaming Backup

Type: DWORD

Value: 0 = default behavior (remote backup disabled); 1 = remote backup enabled

After entering the above registry value, restart the Microsoft Exchange Information Store to apply the change by performing the following steps:

• On a stand-alone server, open a Command Prompt window and run the following commands:

  net stop msexchangeis
  net start msexchangeis
  

• On a clustered mailbox server (CMS), open the Exchange Management Shell and run the following commands:

  Stop-ClusteredMailboxServer <CMSName> -StopReason "Enable Remote Streaming Backup" -Confirm:$False
  Start-ClusteredMailboxServer <CMSName>
  

Third-party applications may require remote streaming backup functionality. Check with your application vendor to determine whether your application requires remote streaming backup capabilities.

Exchange Restores and Continuous Replication

After restoring a database from backup into a storage group that is enabled for LCR or SCR, or any storage group in a CCR environment, you must suspend and then resume continuous replication for the storage group using Suspend-StorageGroupCopy and Resume-StorageGroupCopy, respectively. This process is needed to update the Microsoft Exchange Replication Service with the correct log generation information. If continuous replication is not suspended and resumed, the Microsoft Exchange Replication Service will have outdated log generation information and will stop replicating log files.

For More Information

For detailed information about performing a backup with Backup, see How to Perform a Basic Backup of Exchange Databases. For detailed information about performing a restore with Backup, see How to Perform a Basic Restore of Exchange Databases.

For more information about what needs to be backed up in Exchange 2007, see What Needs to Be Protected in an Exchange Environment.

For complete details about Backup, see Backing up and restoring data in Windows Server 2003 Help.