After ESE restores the specified databases and transaction logs, it begins to apply page splits to the respective databases (see "Checkpoint and Patch Files" for more information about page splits). Next, ESE processes the transaction logs. During this procedure, ESE validates the log signature and generation sequence to ensure that the correct transaction logs are present and are available to recover transactions. If a log signature doesn't match the database signature, ESE returns error -610; if ESE discovers a gap in the log generations, it returns error -611. Either of these errors stops the recovery process before ESE replays any transactions into the database so that you can fix the problem before restarting the restore.
ESE actually reads two sets of logs during the restore. First, ESE processes the logs held in the temporary location, then processes the regular logs that have accumulated since the backup. Transaction logs contain data for all the databases in an SG, so even when you restore only one database, ESE must scan all the data in the logs to isolate the transactions for that database before applying them (ESE ignores all the other data in the logs). This phase of the operation can be the longest, depending on the number of transaction logs that ESE must process.
After ESE applies the transaction log data, the recovery SG performs some cleanup operations, exits, and returns control to the primary SG (i.e., the SG that you're restoring), which brings the newly restored databases back online. ESE also deletes all files in the temporary location.
At the end of a successful restore, ESE writes event ID 902 to the Application log. ESE also records the details of the restore operation in a text file in the temporary directory (the file is named after the backup set). To be certain that everything is OK before you let any users connect to the store, make sure that ESE logs event ID 902 and that ESE has recorded no errors in the text file.
Knowledge Is Power
Understanding the process of creating and restoring a full backup can help any disaster recovery go more smoothly. For more information about Exchange 2000 disaster recovery, see "Disaster Recovery for Microsoft Exchange 2000 Server" (http://www.microsoft.com/exchange/techinfo/deployment/2000/e2krecovery.asp).