Exchange 2010 includes Database Mobility features, which offer significant refinements over Local Continuous Replication (LCR) and Cluster Continuous Replication (CCR), which were introduced in Exchange 2007. The new Database Mobility features enable databases to be replicated among different Exchange servers to improve database availability and site resilience. The other database copies in a Database Availability Group (DAG) provide a valuable opportunity for Exchange backups to use the extra resources available at the copy location. In addition, by backing up the copy instead of the active database master, the time the copy is unavailable during the backup can be longer. To take advantage of DAG copies, Exchange 2010 includes the VSS Replication Writer.

Exchange Writers coordinate with the Exchange services (operating on behalf of the requestor) to prepare the database files for backups, freeze the IO activity resulting from Exchange transactions before backing up the database, and then to unfreeze and truncate log files after the backup is complete.

During a restore, the backup/restore application instructs the Exchange Store Writer to coordinate with the Exchange store (operating on behalf of the requestor) to verify the restore targets, rename the database file if necessary, and then replay the transaction logs as needed. The Store Writer supports both backups and restores, while the Replication Writer supports only backups.

When restoring, the Requestor also communicates with the VSS to prepare the system for the restore, and then to put the data back onto the mass storage device. The backup/restore application is also responsible for working with Windows Server 2008 to read data from and write data to the backup storage media, whether a tape archive, a storage area network, or other backup medium.

Backup and restore applications must specify a number of Exchange Server 2010-specific parameters to correctly control and manage operations run by the VSS against Exchange Server 2010 databases. For example, because Exchange Server 2010 supports up to 100 simultaneously active databases, the backup application must correctly specify and process the database components: database file, transaction log files, and checkpoint file.

Additionally, the Microsoft Exchange Server 2010 Writer for the Windows Server 2008 Volume Shadow Copy Service uses a variety of special settings and values that must be properly set and preserved during backup and restore operations. Without careful control over these settings, the backup application is likely to experience unexpected and potentially confusing errors.

The following interfaces in the VSS are required to get the Exchange Writer metadata document that is needed for the requesting backup/restore application to be able to perform the backup.

Within the Windows Server 2008 file system, an Exchange Server 2010 database is stored as a single database file with an extension *.edb. The Exchange Writers exposes the *.edb as the "database" component, while transaction logs (*.log) and checkpoint files (*.chk) are combined into a single component, referred to as the "log" component.

The high-level interaction between the VSS, the Exchange Writer, and Exchange Server 2010 during backup operations is as follows:

1. The backup program (or agent) runs a scheduled job.
   
2. The VSS requestor in the backup/restore application sends a command to the VSS to take a shadow copy of the selected Exchange Server 2010 databases.
   
3. The VSS communicates with the Exchange Writer to prepare for a snapshot backup. Exchange Server 2010 prohibits administrative actions against the databases, checks volume dependencies, and suspends all write operations to selected instance of the database and transaction log files while allowing read-only access.
   
4. The VSS communicates with the appropriate storage provider to create a shadow copy of the storage volume that contains the Exchange Server 2010 databases.
   
5. The VSS releases Exchange Server 2010 to resume ordinary operations.
   
6. The VSS requestor verifies the physical consistency of the backup set prior to signaling the backup was successful. Exchange Server 2010 truncates the transaction logs (if the database is part of a DAG, log truncation is replicated among all the copies) and records the time of the last backup for the database.
   

Exchange 2010 Writers share the same Writer Name “Microsoft Exchange Writer” and Writer ID “76fe1ac4-15f7-4bcd-987e-8e1acb462fb7” and can be distinguished by a new parameter that is introduced to VSS framework in Windows 2003 SP1, the Writer Instance Name. In Exchange 2010, the instance name of the legacy Store Writer is “Exchange Information Store” and the instance name of the new Replication Writer is “Exchange Replication Service”.

Store Writer will be available on any Exchange Mailbox Server to provide the functionality to backup from and restore to the active copy of the database. Replication Writer will be available for use with copies of databases in a DAG.

Windows 2008 VSS serializes Requestors’ interaction with application Writers starting with OnPrepareForBackup() and ending with OnPostSnapshot(). Typically the majority of time spent working with the shadow copy is spent after the OnPostSnapshot(), when the consistency of the shadow copy is verified prior to completion of the backups. Both Exchange Writers support parallel backups between OnPostSnapshot() and OnBackupComplete().

Concurrent backups of the same database are not allowed in Exchange 2010. There can be only one single backup job running against a given database irrespective of whether the backups are done with the Store Writer or the Replication Writer. This is achieved by Exchange store putting the database in a “backup-in-progress” state, this in-memory state is cleared either at the completion of the backup process or when the service is restarted. When it is used, the Replication Writer communicates with the active database owned by the store process to verify that there is no active backup in progress against the selected database, and then sets the “backup-in-progress” state for the selected databases. Restarting services that host Exchange Writers, complete OS reboots as well as cluster failovers will result in losing the in-memory “backup-in-progress” state together with its associated data, which in turn will cause the backup job to fail.

Backup initiated transaction log file truncation will be triggered based on the type of backup chosen. In non-DAG configurations, the Store Writer will truncate the transaction log files at the completion of successful Full or Incremental backups. In DAG replicated configurations, log truncation will be delayed by the Replication service until all necessary log files are replayed into all other copies. The Replication service will delete the backed up log files both from the active and the copy log file paths after it verifies that the to-be-deleted log files have successfully been applied to the copy database and both active database and the database copies checkpoint has passed the log files to be deleted.