Eseutil /R Recovery 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
Recovery refers to the process of playing transaction log files into a database. There are two kinds of recovery:
Hard recovery: A transaction log replay process that follows a database restoration from an online backup
Soft recovery: A transaction log replay process that occurs after any of the following activities:
a database is remounted after an unexpected stop
transaction logs are replayed into an offline file copy backup of a database
logs are replayed into a Volume Shadow Copy Service (VSS) backup set
For more information about syntax and about running Eseutil /R recovery mode, see How to Run Eseutil /R (Recovery).
Hard Recovery
Hard recovery occurs when transaction log files must be replayed into a restored online backup. In all other recovery scenarios, soft recovery occurs. You can use Exchange Server Database Utilities (Eseutil.exe) to perform a hard recovery by using by using the Restore mode (/C).
Soft Recovery
In the most common soft recovery scenario, an external event unexpectedly stops an Exchange database, but the database and log files remain intact and in place. When the database is mounted again, Exchange reads the checkpoint file and begins to replay the transaction log that is listed as the checkpoint log. If no checkpoint file exists, replay begins at the oldest log file available in the transaction log folder for the storage group.
Exchange writes completed transactions to the database files. These are transactions that are found in the log file and that have not already been written. Exchange then reverses any incomplete transactions. Exchange never begins writing a transaction into the database files until all the operations composing it are secured to the log files. You do not have to physically undo or stop a transaction in the database if all uncommitted transaction logs that exist when the unexpected stop occurs also exist when replay begins.
Important
A fundamental assumption of the soft recovery process is that no database or log files have been moved, deleted, or destroyed either by the failure or by the administrator after the failure.
Specific Recovery Scenarios
The following sections describe various recovery scenarios.
Transaction log files are not in the current folder
Generally, you should always run Eseutil /R from the folder that contains the transaction log files to be replayed. This is because the default soft recovery process looks in the transaction log files to find the path to the databases. If you run Eseutil /R from a folder in which no log files exist, a new transaction log file is generated, and this new log file will not contain the location of the databases. If you want to run a soft recovery from outside the transaction logs folder, add the following switch to the command:
/Lpath_to_logfiles
For example, add this switch:
Eseutil /R E00 /Ld:\exchsrvr\logfiles
Controlling the checkpoint file
When you manually run a soft recovery, you usually want to either delete or hide the checkpoint file. This is because, typically, you want to replay all available transaction logs instead of starting from the middle of an available sequence.
If you are running a soft recovery from a folder that contains a valid checkpoint file, and you do not want to have that file affect recovery, you must define a different path for a checkpoint file to be created during recovery. This might be required after you restore an offline backup to a storage group in which databases are running.
If you are running recovery from a different folder, and you want to use the checkpoint file to control recovery, you must point to the path for the checkpoint file.
If you want to control the use of the checkpoint file during a soft recovery, add the following switch to the recovery command:
/Spath_to_or_away_from_current_checkpoint
For example, add this switch:
Eseutil /R E00 /Sd:\
Recovering a storage group with a missing mailbox or public folder database
If a storage group is unexpectedly stopped, and one of the inconsistent mailbox or public folder databases is removed or unavailable, you cannot mount any of the databases in the storage group until you restore the missing database or until you run manual recovery by using the /I switch.
Important
Before you run a recovery that ignores the missing mailbox or public folder database, you should make a backup copy of all transaction log files, including the current log file, (Enn.log). Enn.log is changed through the process of recovering the other databases. After this, it may not be useable for recovering the missing database if it is made available again.
Recovering a database out of place
Recovering a database that is out of place completely isolates the recovery process from the running storage group. Use this method when you want to recover an offline backup in a recovery storage group, and you intend to play any log files into the backup.
To prepare to do this procedure, you should move the database file and all transaction logs that you intend to play into a single temporary folder. From this folder, you can run the following command:
Eseutil /R Enn /I /D
For example, run this command:
Eseutil /R E00 /I /D
The /I switch may not be necessary, depending on whether there are clean shutdown records in the transaction logs for other databases that were attached to the logs. Using the switch in this circumstance is recommended so that you do not have to start recovery again if there is a hanging attachment somewhere in a log file.
If the /D switch does not exist, the database paths that are recorded in the transaction log files are used to locate the databases. If the /D switch is used without a path, the current directory is used as the path for the database files. If the /D switch is immediately followed (with no intervening space) by a file path, that path is used to locate the database files.
To avoid typing errors, we strongly recommend that you eliminate the need for using paths that have Eseutil switches whenever possible . To do this, run Eseutil from a folder in which all data files already exist.
After recovery finishes and the database files are in clean shutdown state, the files may be moved into the appropriate storage group and attached to the log files, thereby mounting the databases.
Note
To make sure that a database mounts, you may have to click to select the This database can be overwritten by a restore check box on the database object properties in the Exchange Management Console.
Recovering a database that has missing log files
In Exchange Server 2007, a new feature named Lost Log Resilience (LLR) protects Exchange databases from losing the last few log files, and enables faster recovery. When an LLR-protected log file is missing or corrupted, typical database mounting or recovery by using Eseutil fails and does not provide the new /A recovery option. Event ID 523 is logged to the Event log and states the kind of failure that occurred. On a database on which an LLR-protected log file is missing or corrupted, you can run Eseutil recovery by using the /A option in recovery mode as follows:
ESEUTIL /R Enn /A
By default, in a non-clustered Exchange Server 2007 server, only the last file is protected by LLR. Therefore, this option can be used only when the last transaction log file is missing. For more information, see Lost Log Resilience and Transaction Log Activity in Exchange 2007.
Note
You can see the command-line reference and syntax for Eseutil by typing eseutil /? at a command prompt. However, the /A option is not listed in the Exchange 2007 RTM version of the command-line reference.
When you recovered a database that had missing log files in previous versions of Exchange, you would have to either restore databases from backups or repair the existing database file by using Eseutil /P. With Exchange 2007, database recovery is enhanced so that you can recover a database that has log files missing in the LLR range by running the recovery command and using the /A option.
For More Information
For more information about Eseutil, see the following topics: