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.
Note
Windows Server Backup in Windows Server 2008 no longer supports Exchange-aware backups or restores. Unlike earlier versions of Windows Backup, you cannot make or restore streaming backups of Exchange by using Windows Server Backup. Therefore, to back up and restore Exchange Server 2007 SP1 or Exchange 2007 RTM on Windows Server 2008, you must use an Exchange-aware application that supports the Volume Shadow Copy Service (VSS) writer for Exchange 2007, such as Microsoft System Center Data Protection Manager, a third-party Exchange-aware VSS-based application, or a third-party Exchange-aware application that uses the streaming backup APIs locally on the Exchange server to make a backup locally on the Exchange server. An application that uses a backup agent that runs locally on the Exchange server and streams the backup remotely to a backup application is considered a local backup.
However, Exchange 2007 SP2 includes a new plug-in that enables you to make Volume Shadow Copy Service (VSS)-based backups of Exchange data using Windows Server Backup in Windows Server 2008. You can use Windows Server Backup to back up and restore your Exchange 2007 SP2 databases. 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 Using Windows Server Backup to Back Up and Restore Exchange Data.
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.
Note
You cannot back up a target storage group in a standby continuous replication (SCR) environment. Backups of storage group copies are available for LCR and CCR environments only.
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.
Note
To perform a VSS-based backup of a passive storage group, you must use a third-party backup application that supports Exchange VSS.
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.
Note
Remote streaming backups or restores are not supported on or from Windows Server 2008.
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 msexchangeisOn 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.