Restoring to a Recovery Database

The Exchange Server 2010 Writer adds the ability to restore data directly to a recovery database. Mounting the recovered data as a recovery database allows the Exchange administrator to restore individual mailboxes, and even individual items in a mailbox.

Restoring to a recovery database can be accomplished in two ways. If a recovery database already exists, the application can dismount the database, restore the data onto the recovery database and log files, and then remount the database.

Each Exchange 2010 server supports only one Recover Database mounted at a time. The server can contain as many recovered databases as disk space allows, but only one can be mounted as the Recover Database. The database mounted as the Recovery Database is counted in the maximum number of databases that can be mounted at a time. A recovered database mounted as a server’s Recovery Database is not tied to the original mailbox in any way.

Alternatively, the database and log files can be restored to any disk location. The Exchange Server 2007 writer analyzes the restored data and replays the transaction logs to bring the databases up to date, and then a recovery database can be configured to point to already-recovered database files.

To recover to a recovery database, the application must call the SetRestoreOptions() method and provide an XML document that indicates the source and target database GUIDs. The source GUIDs must match those from the backup set, and the target GUIDs must match the destination database entries in Active Directory. The backup application must also call AddNewTarget() to specify the directory path where the files are restored to. If the database files needs to be renamed, Exchange Writer will rename the database during OnPostRestore(). Exchange requires the transaction log files to be restored to a sub folder (_restoredLogs) under the current transaction log file path, if the log files are restored to any other location Writer will return an error. Since databases being mounted as the Recovery Database are not restored to their original location, they need to be brought into clean-shutdown state before they can be mounted. By default the Exchange writer will bring all the restored databases into a clean-shutdown state during post-restore. If backup application calls SetAdditionalRestore() Exchange Writer will not replay the log files, and either the administrator or the backup application needs to bring the database into a clean-shutdown state prior to mounting the database.