Eseutil /C Restore Mode

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

The Exchange Server Database Utilities (Eseutil.exe) restore mode can only be run on mailbox and public folder databases restored from legacy streaming backups. This topic does not apply to transport queue databases on the Edge and Hub Transport server roles because the queue databases are not backed up. The Eseutil restore mode also allows you to view the Restore.env file. The Restore.env file is created when restoring an online backup of the database, and it controls the hard recovery process.

Hard recovery is the process that changes a restored database back to its clean shutdown state by playing transactions into the database from transaction log files. The hard recovery process controls transaction log file replay into a database that has been restored using the legacy streaming backup application programming interface (API). This process is different from a soft recovery that takes place after restoring a database using the Volume Shadow Copy Service (VSS) backup API as well as after recovering from a failure.

Backup applications that implement the Exchange legacy streaming backup API provide a setting in the user interface to start hard recovery after the last backup set has been restored. In Microsoft Windows NT NT Backup, this is called Last Backup Set.

If you fail to trigger hard recovery from the backup application, you must run hard recovery manually from the command prompt with Eseutil before a restored database can be mounted. To initiate hard recovery, you can select the Last Backup Set check box in the backup API when you restore your last database, or you can use the Eseutil /CC command. In this command, the first /C indicates restore mode and the second C is the mode modifier to start the hard recovery process. The hard recovery process uses the Restore.env file that is generated during the restore process to determine how to restore the database files and to determine what transaction log files must be replayed from the temporary directory that the backup was restored to. After the databases are copied to their destination location, and the transaction log files from the temporary directory are replayed into them, hard recovery continues to replay any additional transaction log files that it finds in the transaction log file path specified for the storage group of the restored database.

For instructions and syntax for running Eseutil /C, see How to Run Eseutil /C (Restore).

Controlling Transaction Log File Replay

Transaction log file replay behavior using Eseutil /CC depends on whether the database has been victimized. If you are restoring to an alternative server, or you have deleted and re-created the original database, only transaction logs in the temporary folder are replayed. Transaction logs in the normal database folder are not replayed. This distinction avoids transaction log replay conflicts in cases where Exchange Server knows that the database to which it is restoring is not the same as that from which it was backed up. A database restored in this circumstance is called a victimized database.

If a database has not been victimized, transaction logs will be replayed as follows:

• The sequence of log files listed in the Restore.env file will be replayed first.

• If additional log files exist in the Restore.env location, they will not be replayed under any circumstances.

• If additional matching log files exist in the running storage group log folder and they are in contiguous sequence with the files listed in Restore.env, they will be replayed.

• If additional log files exist in the running storage group log folder, and they do not match or are not in contiguous sequence, and circular logging has been disabled, an error will occur and hard recovery will fail. To resolve such errors, matching and contiguous log files must be located, or you can use Eseutil /CC /T switches to ignore log files in the running folder and to replay only log files listed in Restore.env.

• If circular logging is currently enabled or was enabled at the time the backup was made, only log files listed in Restore.env will be replayed.

• If no log files exist in the running storage group log folder, recovery will complete successfully using only the log files listed in Restore.env.

If a database has been victimized, transaction logs will be replayed as follows:

• The sequence of log files listed in the Restore.env file will be replayed first.

• If additional log files exist in the Restore.env location and they match and are contiguous with the logs listed in Restore.env, they will also be replayed.

• Additional log files in the running storage group log folder will not be replayed.

If a database has been restored to a recovery storage group, transaction logs will be replayed as follows:

• Any other databases in the recovery storage group must be dismounted before beginning any transaction log file replay.

• The sequence of log files listed in the Restore.env file will be replayed first.

• If additional matching log files exist in the running log folder for the recovery storage group and they are in contiguous sequence with the files listed in Restore.env, they will be replayed.

• If additional log files exist in the Restore.env location, they will not be replayed under any circumstances.

For More Information

For more information about database recovery, see Disaster Recovery Strategies.

For more information about Eseutil, see the following topics:

• Eseutil /D Defragmentation Mode

• Eseutil /P Repair Mode

• Eseutil /R Recovery Mode

• Eseutil /G Integrity Mode

• Eseutil /M File Dump Mode

• Eseutil /K Checksum Mode

• Eseutil /Y Copy File Mode

• Reference for Common Eseutil Errors