Restoring to the Original Location
The Microsoft Exchange Server 2010 writer enables applications to restore databases and transaction log files to their original locations on the Exchange server. By default, the Exchange 2010 writer replays the transaction log files after it is informed of the completion of the restore by the requester during the OnPostRestore operation. To prevent replaying of the log files, the backup application must use the VSS SetAdditionalRestore function. If the Exchange 2010 writer doesn’t perform the log replay, the log replay can be performed when the Exchange administrator or the application remounts the restored storage group or database.
When restoring databases back to their original database objects (that is, such that the target GUIDs in the database match those in the backup set) but to different file paths, the application must determine the current file paths and restore the backup files to the corresponding file paths specified in the database properties. The requester must call the AddNewTarget function to communicate to the Exchange writer the location where the files are restored before the writer can continue with the rest of the restore process. If AddNewTarget is not called, the Exchange writer will assume that the backups are restored to the file paths specified in the backup metadata document.
Typically, backups performed from a Database Availability Group (DAG) copy by using the Replication Writer — as well as backups done with the Store Writer — don’t need to have new paths specified, as Exchange administrators will usually not be changing database or log file paths. In a DAG configuration, however, a backup performed by the Replication Writer might require the backup application to specify the active database and log paths, because DAG copy paths are always different from those paths.
Note that Exchange 2010 does not support restoring inactive DAG database copies. The only supported situation in which DAG copies can be restored from backup data is when the active database copy is restored, and then . Using different backup data sets or attempting to restore fewer than all of the database copies can result in the database being unmountable.
Backup applications do not have to call the SetRestoreOptions function in this case, because the backups are restored to the original database objects they were created from. However, if the backup application calls SetRestoreOptions and the XML metadata document has the correct parameters, the result is not an error.