How and when to manipulate Exchange transaction logs in disaster recovery

This article describes the modification of transaction logs during disaster recovery of Exchange servers. This process is generally known as renaming of logs.

Definitions

This article describes the following terms:

Soft recovery

Soft recovery is a process that occurs if an Exchange information store that stopped abnormally is brought online. When the store stops abnormally, the checkpoint file tracks which transaction log must first be replayed to return the database to consistency. Note that soft recovery requires that EDB/E00.log, the highest log, is present.

Hard recovery

Hard recovery is a process that occurs when you apply transaction logs and database patch files before Exchange 2000 Service Pack 2 (SP2), to a database that has been restored from an online backup. Note that hard recovery does not require that EDB/E00.log, the highest log, is present.

When not to manipulate log files

Do not manipulate log files if a failed soft recovery on the database has already occurred. Soft recoveries can fail for a number of reasons, including a damaged log file. For example, you tried to mount the store after the server stopped responding, but the mounting failed because one of the log files was damaged. In this situation do not try to manipulate the logs in any way. When you tried to mount the store, information about the bad log file was committed to the database, so the database will not soft recover if you remove the bad log file or rename the last known good log file to E00.log.

Example troubleshooting scenario

You are troubleshooting an Exchange Server 5.5 or Exchange 2000 Server computer. The Information Store service terminated and there are 10 logs files on the hard disk. These log files range from E0000010.log to E0000019.log, and end with E00.log. You restart the Information Store service. The Extensible Storage Engine (ESE) then starts replaying the log files, but reports that the E0000015.log file is damaged. You try renaming the E0000014.log file to E00.log, and then try to mount the store again. This does not work. This is designed to fail because damaged information from the E0000015.log file may have already been committed to the database.

Completing a hard recovery does not require that log files be renamed

Only manipulate logs files after a database has been restored, but before hard recovery has completed on the database. Only try to manipulate log files before you play restored or resident logs back into the restored database. Note that in this scenario, no log file renaming is actually required.

Example troubleshooting scenario

Continuing the troubleshooting scenario that was previously described, the E0000015.log log file has been damaged. Because of this, the E0000015.log file and all later logs cannot be reused, including the E00.log file. To make the largest recovery possible, remove all the logs from E0000015.log to E00.log. Known good logs E0000010.log to E0000014.log will remain on the disk. Then remove the checkpoint file. After you remove the checkpoint file, restore the online backup of the database. This restores the database and any log files that were included on the media backup. The log files that are restored will all be "older" than the E0000010.log file. When you have completed the restoration, the Hard recovery runs. The Hard recovery plays through the logs that were restored from tape, and then continues playing through logs that resided on the disk, E0000010.log through E0000014.log. After the logs have been played through, the database is mounted.

Note No log file renaming was required. Hard recovery does not require that the E00.log file be replayed to successfully complete.

When to manipulate the log files

The only time you should rename log files is if Soft recovery has not yet failed on the database.

Example troubleshooting scenario

You are troubleshooting an Exchange 2000 Server computer. Logs E00000A1.log through E00000A7.log and log E00.log are all on the disk. The Exchange server crashes, and your database is damaged during the crash. When you investigate, you notice that the E00.log is also damaged. You have an offline backup of the database from yesterday. When you dump the checkpoint file, you notice that the last four logs were not committed to the database before the crash. To recover from this scenario:

1. Restore yesterday�s offline backup.
2. Rename the E00000A7.log file to E00.log.
3. Remove the checkpoint file.
4. Mount the store.
5. Soft recovery runs, playing all the logs into your database.
6. The database has been returned to a consistent state.

Conclusion

Log manipulation will not work if Soft recovery has already been tried, but did not work. Only remove damaged (and later) log files if you will be completing a Hard recovery, complete with a restoration from an online backup and replaying of available log files. Hard recovery does not require the E00.log file to complete successfully. Instead, it only requires that damaged log files are removed before you start. The only scenario when log files can be renamed is if you restore a previous offline backup, and the log files on the drive are damaged.

For additional information about related topics, click the following article numbers to view the articles in the Microsoft Knowledge Base: