Introduction to Exchange Server Soft Recovery and hard recovery

When using Microsoft Exchange Server 2003, you must note the differences between recovery and recovery. Restoration refers to the restoration of databases and log files to the server. Restoration refers to the replay of transaction logs to the recovered database.

There are two forms of recovery:

Soft Recovery refers to the log replay process when the database is reloaded unexpectedly after it is stopped, or when the transaction log is replayed to the offline backup of the database.

The replay process of the hard recovery transaction log occurs after the database is recovered from the online backup.

　　Soft Recovery

In the default soft recovery scenario, an external event unexpectedly terminates the Exchange Server database, but the database and log files remain intact and remain in the original location. When the database is reloaded, exchange reads the checkpoint file and starts to replay the transaction logs listed in the checkpoint log. If no checkpoint file exists, replay starts from the oldest available log file in the transaction log folder in the storage group.

The Exchange server writes them to the database to complete the transactions found in those log files that have not been written to the database. The Exchange Server never writes transactions into database files until the entire composition of all operations is securely placed in log files. You do not need to physically cancel or reclaim a transaction in the database. When the replay starts, if all the uncommitted transaction logs are still in the process, unexpected suspension occurs.

Important information: a basic assumption in the soft recovery process is that no database or log files are moved, deleted, or damaged by the Administrator due to a fault or after a fault.

If you delete any required transaction logs from the replay sequence, the soft recovery of the Exchange server will immediately fail. If the required logs are lost, you must restore them from the old logs and from the Database Backup (one without those log copies), or you must use the Exchange server data warehouse tool (eseutil.exe) to fix the database.

　　Basic rules for transaction log file Replay

Some basic rules for transaction log file replay are as follows:

1. You cannot replay log files from one database to another. Operations in log files are low-level. You cannot see what is in the log file like "transfer mail a to mailbox B ". A good example of Log File Operations is "Writing 7890 bytes of stream to offset 123 bytes on the database page 456 ".

Imagine that you want to edit a document and give some instructions. Your instructions are "insert 'yes or no 'after the second word in the third sentence in the fourth section of the fifth page '". If these commands are applied to the document rather than where you intend, the document will be randomly damaged. Similarly, if an error log file is replayed to an Exchange Server database, similar results will occur. Therefore, the Exchange server must have multiple security mechanisms to prevent such damages. If you repair or organize the Exchange Server database, the transaction logs associated with the database cannot be replayed to it.

If you try to replay logs after they are fully organized or repaired, the Exchange Server skips these incorrect transaction logs. Consider editing similar documents again. If a segment is moved, edited, or deleted because the directive is created, the expired directives of the application are broken because they are converted into a completely different document.

2. You cannot replay log files unless all unsubmitted log files are available from the database when it was last run. You must have all log files backed up from the checkpoint and at that time. Then you can replay the log files from this point as long as they do not have an interrupted sequence. If a single file is lost at the beginning of the intermediate or sequence, the replay will stop there.

3. You cannot replay log files if the database files have been moved to different file paths (before Exchange 2000 Server SP2 ). This restriction is not applied if you are using Exchange 2000 Server SP2 or later renewal, because eseutil.exe processes replay even if the path has been changed. The following section describes how the replay process works.

4. You cannot replay the log file if the checkpoint points to the error log. The Exchange Server treats the checkpoint log as if it was the first available log and ignores all old log files. If you have restored the backup of the old database file, the check point will return to the previous long distance, and the Exchange Server tries to replay from a very new log file. You can solve this problem by deleting the checkpoint file, which forces the Exchange Server to scan all available log files. (If you restore an online backup, hard recovery ignores the checkpoint file .)

5. You cannot replay log files if any database files in the storage group have been deleted. All previously running databases that suddenly experience unexpected termination must exist to ensure successful Soft Recovery. This restriction can be used to run soft recovery through eseutil.exe.

If other databases in a storage group are running soft recovery, then a database is lost, and the log replay in the future will become more complex. Failed to use soft recovery, the Exchange Server gave the Administrator a chance to analyze the situation and decide whether to handle it through the database.

　　Advanced soft recovery scenarios

In most cases, the best way to run soft recovery is to load any database in a storage group. Because all databases in a storage Group share the same log file stream, soft recovery occurs at the level of the entire storage group rather than at the level of a single database.

In a specific environment, using eseutil.exe to run Soft Recovery is advantageous. The following scenarios are the most common examples.

1. You want to restore a storage group with lost databases.

2. You want to restore a separate database that has exceeded space without affecting the log files of other databases or storage groups.

The complete syntax of the eseutil.exe soft recovery function lists all possible switches as follows:

Eseutil/r enn/L [path to log files]/s [path to checkpoint file]/d [path to database file]/I

For example, enter the following command in the command line:

Eseutil/R e01/LF:/mdbdata/SC:/exchsrvr/mdbdata/DG:/mdbdata/I

Note: The eseutil.exe command line parameters are not case sensitive. They are mixed together in the preceding example to avoid confusion between the "L" and "I" characters.

This example shows that the storage group database is restored. The log file prefix is e01, the log file is located at F:/mdbdata, the checkpoint file is located at C:/exchsrvr/mdbdata, and the database and stream file are located at G: /mdbdata, the lost database is ignored (because of the/I switch at the end ).

The cmdeseutil.exe command line for running Soft Recovery is:

Eseutil/R ENN

This command takes effect only when the transaction log directory is set in the prompt. You should use eseutil.exe to run soft recovery:

1. If you do not specify which file is in the command line, eseutil.exe uses your current command line directory as the default directory for log files and checkpoint files.

2. The database file is not necessarily in the log file path. Because eseutil.exe finds that all database paths read log files. Use the/D switch to overwrite the path stored in the log file only when you confirm that the path of the log file is incorrect.

3. If the checkpoint file is not in the same path as the transaction log file, all scanned log files should be replayed instead of starting from the checkpoint. You can temporarily copy an existing checkpoint file to the log file path. After the soft recovery is complete, exchange does not use the checkpoint copy in normal database operations. If the information in the checkpoint file is incorrect, Soft Recovery will fail but will not damage the database. You can try to restore the checkpoint file or find the correct checkpoint file. The checkpoint file is not the most fundamental for the successful operation and recovery, but it can save a lot of time if you have a large number of log files.

If you want to start recovering a database from a storage group, you can use the following command:

Eseutil/r enn/I

The/I switch means that the lost database is ignored. If you use this switch to load the lost database, the Exchange Server prompts you to create a new database. If you plan to restore the old database at some points, you will not be able to replay new data into it. You now have two separate versions of the same logical database.

In this case, a database in the storage group has been replaced by an empty database, which can be helpful for restoring the storage group. You can use the mailbox combination wizard (exmerge.exe) to add the content of a database to other databases.

If you want to start restoring a database without affecting other databases in the storage group, you should create a new empty folder and move the database files you want to restore, the transaction log you want to replay and the checkpoint file (if needed) to this path. The path must not contain other database files.

After you isolate the database and logs to a folder, run the following command from that folder:

Eseutil/r enn/I/D

By using the/D switch without specifying a path, you can overwrite the database path in the log file. In addition, because this folder does not have other databases available, you can hide other databases on the server from this specific recovery process.

If you do not use the/d parameter correctly, the restoration process can affect other databases on the server. Even in the worst case, the recovery process will not damage other databases. However, the recovery may fail on the database you are working on. This restoration operation may even affect the log replay capability of other databases.

Note: increase the possibility of errors because the command line is more complex. To minimize the specified path information in the command when using eseutil.exe. In this case, switch to the directory where the log file is located and include the/exchsrvr/bin directory in your system path.

To run Soft Recovery, the last log file in the replay sequence must be named ENN. log. If the last log file has been closed and counted, you must rename it before Soft Recovery is successful. This requirement does not mean that the current ENN. log file has been corrupted. You can ignore it and rename the previous log in the ENN. Log sequence. On the Exchange 2000 Server, logs required in the database header lists the minimum number of logs required for restoration, starting from the checkpoint log and continuing to the current log. In earlier versions of the Exchange Server, even if there is no logs required value to force the required log to exist, the restoration will still fail if the last log is not found. The only difference between an Exchange 2000 Server and a later version is that the restoration will fail at the end of log replay rather than at the start.

　Hard recovery

Hard recovery must be completed after restoration from online backup. Hard recovery is a log replay process similar to soft recovery, but there are some important differences. In hard recovery, these differences include:

1. Patch information must be applied to the database during Log File replay.

2. Check Point files are ignored. Use restore. env instead of checkpoint to determine the log file from which the recovery should begin.

The Administrator of the Exchange Server 5.5 may be familiar with restoring the registry. Restore. env replaces the key function on the Exchange 2000 Server. You can view the content of the Restore. env file by running the eseutil/cm command.

1. If the database has been restored to a different path from the previous backup, the log file is replayed successfully, ignoring the database path listed in the log file.

2. The restored transaction log file may be replayed from the Temporary Folder specified by the administrator before being replayed in the normal transaction log folder restore. log.

3. Hard recovery will not fail if other databases in the storage group are lost.

The database files (. EDB and. STM) restored from the online backup set are restored to the normal path of the specified database. Restore starts by overwriting existing database files. If you have a chance that you may need existing database files in the future, you must move them or back them up before restoring them from online backup. The restoration of online backup may fail for other reasons. Even if the existing database files cannot be started at that time, they may still be repaired and the data can still be used if necessary.

When you begin online backup recovery, the Exchange Server prompts you to provide a temporary folder location. The backup program restores the transaction log from the backup set to this location, instead of the normal transaction log file path. The backup program also creates the Restore. env file in the Temporary Folder.

The Restore. env function in hard recovery is similar to the checkpoint file in Soft Recovery. Restore. env defines the range of transaction log files that should appear in the Temporary Folder for hard recovery. If you place additional logs in a Temporary Folder-they are out of the range listed in Restore. env-they are not replayed and the recovery process may automatically delete them.

You may have additional log files that are not in the online backup set to be replayed. In this case, place these logs in the normal transaction log folder of the storage group rather than the Temporary Folder. After the hard recovery is restored from the replay log in the backup set, the process checks the normal transaction log folder to see whether the next log in the sequence is available.

Note: If you restore to the backup server, or you have deleted and re-created the original database, only the transaction logs in the Temporary Folder are replayed. Transaction logs in the normal database folder are not replayed. This feature prevents conflicts caused by transaction log replay in case the Exchange Server knows that the restored database is different from the backup. In this case, the restored database is called the "deleted" database.

You can play additional transaction logs for the deleted database by placing them in a temporary folder. In this special case, the recovery process does not delete or ignore them, but replays them. If you suspect that you want to restore the environment, place copies of the additional transaction logs in both the temporary folder and the normal database folder. Regardless of the database deletion status, the restoration process replays one or more log sets. When you restore to the restored storage group, replay takes effect just as you restore to the source storage group. You can place additional logs in the recovery storage group database folder, and the additional logs in the Temporary Folder will be ignored and deleted.

For example, assume that there are 6 log files, e0000003.log to e0000008.log, and restore from backup to Temporary Folder. After these log files have been played, restore the e0000009.log file that now checks the running log folder for the same log sequence. The internal flag in the log file verifies that they are shared. The replaying policy is not executed only based on the log file name.

If log file 9 is found, replay continues as long as the next log in the sequence is available. If log file 9 does not exist, create a new log file named e00.log in the Temporary Folder during the recovery process. This log file is only used to record changes in the database that need to be closed in a consistent state. At this point, the database is completely restored. It automatically restarts and attaches the latest log files in the storage group. The recovery process then deletes all files in the temporary directory.