I got asked this today and just to confirm I was kinda right I thought I would share it! ;-)
Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003
http://technet.microsoft.com/en-us/library/aa997761(EXCHG.65).aspx
As used in Microsoft® Exchange Server 2003, the word recovery must be distinguished from the word restore. Restore is the act of putting database and log files back into place on a server, and recovery is the act of replaying transaction logs into the restored database.
Types of Recovery
There are two forms of recovery:
- Soft recovery A transaction log replay process that occurs when a database is re-mounted after an unexpected stop, or when transaction logs are replayed into an offline file copy backup of a database.
- Hard recovery A transaction log replay process that occurs after restoring a database from an online backup.
Soft Recovery
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 back out a transaction in the database if all uncommitted transaction logs present at the time of the unexpected stop are present when replay begins.
Hard Recovery
Hard recovery must be completed after restoring from online backup. Hard recovery is a log file replay process that is similar to soft recovery, but there are some important differences. In hard recovery:
- Patch information must be applied to the database during log file replay.
- The checkpoint file is ignored. Restore.env is used instead of the checkpoint file to determine from which log file recovery should start.
Exchange 5.5 administrators may be familiar with the Restore in Progress registry key. Restore.env replaces the functionality of that key in Exchange 2000. You can view the contents of the Restore.env file by running the command Eseutil /cm. - If the database has been restored to a different path than that from which it was backed up, log file replay succeeds, ignoring the database paths listed in the log files.
- Restored transaction log files replay first from a temporary folder designated by the administrator before restore. Log files from the normal transaction log folder may also be replayed.
- Hard recovery does not fail if other databases in the storage group are missing.
Database files (.edb and .stm) restored from an online backup set are restored to the normal paths defined for the database. Restore begins by overwriting existing databases files. If there is any chance that you might need the existing database files in the future, you must move them or back them up before restoring from online backup. Take into consideration that restore of the online backup could fail for any number of reasons. Even if the existing database files cannot be started at the moment, they are probably still repairable, and data could still be salvaged if necessary.
As you begin restoration of an online backup, Exchange prompts you to provide a temporary folder location. The backup program restores transaction log files from the backup set to this location, not to the normal transaction log file path. The backup program also creates the Restore.env file in the temporary folder.
The function of Restore.env in hard recovery is similar to that of the checkpoint file in soft recovery. Restore.env defines the range of transaction log files that should be present in the temporary folder for hard recovery. If you place extra logs in the temporary folder—logs that are outside the range listed in Restore.env—they are not replayed and the recovery process may delete them automatically.
You may have extra log files to replay that are not from an online backup set. In this case, place those logs in the normal transaction logs folder for the storage group and not in the temporary folder. After hard recovery finishes replaying the logs restored from the backup set, the process checks the normal transaction log folder to see if the next log in sequence is available.
flaphead.com 