Hard recovery occurs when transaction log files must be replayed into a restored online backup. In all other recovery scenarios, soft recovery is done. Hard recovery can be done with Exchange Server Database Utilities (Eseutil.exe) by using the Restore mode (/C).

In the default 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 with the oldest log file available in the transaction log folder for the storage group.

Exchange writes to the database files completed transactions found in the log file that have not already been written and reverses any incomplete transactions. Exchange never begins writing a transaction into the database files until all the operations composing it have been secured to the log files. You do not need to physically undo or stop a transaction in the database if all uncommitted transaction logs present at the time of the unexpected stop are present when replay begins.

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 where the transaction log files to be replayed exist. 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 where no log files exist, a new transaction log file will be generated, and this log file will not know where the databases are. If you want to run a soft recovery from outside the transaction logs folder, add this switch to the command:

For example:

Controlling the checkpoint file

In most cases where you manually run a soft recovery, you will want to either delete or hide the checkpoint file, because you will typically want to replay all available transaction logs rather than start from the middle of an available sequence.

If you are running a soft recovery from a folder where a valid checkpoint file exists, 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 restoring an offline backup into a storage group where databases are running.

If you are running recovery from a different folder, and 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 this switch to the recovery command:

For example:

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 will be unable to mount any of the databases in the storage group until you restore the missing database or until you run manual recovery with the /I switch.

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 you intend to play into a single temporary folder. From this folder, you can run the following command:

For example:

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 is not present, the database paths recorded in the transaction log files will be used to locate the databases. If the /D switch is used without a path, the current directory will be 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 will be used to locate the database files.

Because of the possibility of typing errors, we strongly recommend that you eliminate the need for using paths with Eseutil switches by running Eseutil from a folder where all data files already exist, whenever possible.

After recovery finishes and the database files are in clean shutdown state, they may be moved into place in the appropriate storage group and attached to the log files, thereby mounting the databases.

Recovering a database with missing log files

In Exchange Server 2007, a new feature called 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 corrupt, normal database mount or recovery with Eseutil fails without the new /A recovery option. An event log with Event ID 523 states the type of failure. You can run Eseutil recovery on a database when an LLR-protected log file is missing or corrupt by using the /A option in recovery mode as follows:

ESEUTIL /R Enn /A

Prior to Exchange 2007, when recovering a database with missing log files, you would have to either restore databases from backups or repair the existing database file using Eseutil /P. With Exchange 2007, database recovery is enhanced where you can recover a database that has log files missing in the LLR range by running the recovery command with the /A option.

For more information about Eseutil, see the following topics:

• Eseutil /D Defragmentation Mode
  
  
• Eseutil /P Repair Mode
  
  
• Eseutil /C Restore Mode
  
  
• Eseutil /G Integrity Mode
  
  
• Eseutil /M File Dump Mode
  
  
• Eseutil /K Checksum Mode
  
  
• Eseutil /Y Copy File Mode
  
  
• Reference for Common Eseutil Errors