Microsoft Exchange 2000 Server supports multiple storage groups, multiple databases, and multiple instances of Extensible Storage Engine (ESE) on each server. Each instance of ESE manages log files for a particular storage group. Databases within the same storage group share the same set of log files. There is also one reserved instance of ESE specifically for online backup and restore.

Exchange 2000 Server database architecture provides some isolation among the multiple databases in a storage group, which allows you to perform maintenance on one database without affecting the other databases in the storage group.

The following is a brief overview of the transaction log file replay process after an online restore of a single database:

1. The database files, .edb and .stm files, are copied to the original location. ESE checks the Restore.env file for this information. By default, the original location is: Drive:\Program files\Exchsrvr\Mdbdata
   
2. All of the log files and patch files, .log and .pat files, from the backup tape are copied to the temporary folder that is specified during the restore operation, specified in the Log Path box. The Restore environment, the Restore.env file, is also created in this folder.
   
3. The ESE instance used for the restore process replays these log files to the database. This only happens if you select the Last Backup Set check box during the restore operation. Then, the ESE instance running against the storage group checks to determine which production log files it needs to replay next.
   
4. Before starting the replay process, ESE checks the log file sequence and warns you if a log is missing or does not match the logs from the backup set. In this case, ESE only replays the logs from tape and brings the database to a consistent state.
   

   Note:
   Data created since the restore will be lost unless you can provide the missing log files. Additionally, note that since Exchange 2000 Server Service Pack 2 (SP2), Exchange does not use and cannot restore backups that have used the .pat files. For more information, see the For More Information section.

If a database is stopped abnormally, the checkpoint file, E00.chk, records the transaction log from which soft recovery must begin replay to restore the database to consistency. This process is called soft recovery. It can be contrasted with hard recovery, which is the process by which log files are replayed after restoration of an online backup. The most important difference between soft and hard recovery is the interpolation of patch file data into the log file replay process during hard recovery.

Hard recovery is the process through which you apply transaction logs and database patch files to a database that has been restored from online backup.

Usually, you select the Last Backup Set check box in Microsoft Windows NT® Backup to start hard recovery. If you forget to select this check box, you must either restore the backup again and this time select the Last Backup Set check box, or run the eseutil /cc command.

Run the eseutil /cc command from a command prompt in the temporary folder where the Restore.env file exists.

In Exchange Server version 5.5 and earlier, the restore process created a registry subkey named RestoreInProgress, which is located under the following registry key (in case of restore of Information Store):

HKEY_Local_Machine\System\CurrentControlSet\Services\MSExchangeIS

The function of the RestoreInProgress registry key is to keep information about the restore environment during the restore process. For example, the RestoreInProgress registry key keeps track of the Exchange Server transaction log files that need to be replayed.

In Exchange 2000 Server, this information is no longer stored in the registry, but is kept in a file called Restore.env. This file is located in the Log Path folder selected during restore, and gets updated during incremental backups. The log file range is updated with all transaction logs restored in previous restore sessions.

You can also view the content of the Restore.env file by running the following command.

  Eseutil /cm "Path of directory where restore.env file is located"

The following are some important values in the Restore.env file:

• Restore log file and Restore Path   This is the location of the Restore.env file and the files, .log and .pat files, that come from the tape that are needed to recover the database. It is specified by the user during restore.
  
• Backup Instance   This is the storage group that the database or databases belong to.
  
• Databases   This is the number of databases restored. A database consists of an .edb and an .stm file.
  

  Note:
  The next four values (Database Name, GUID, Source Files, and Destination Files) refer to one database. If multiple databases are restored, these values are shown once for each database.

• Database Name   The name of the database.
  
• GUID   The globally unique identifier for the database.
  
• Source Files   The paths to the database files when they were backed up.
  
• Destination Files   The paths to the database files when they were restored.
  
• Log files range   The range of log files, inclusive, that were restored. All of the log files must be present to run recovery.
  
• Recover Status   Displays recoverNotStarted if recovery has not been attempted, and recoverEnded if recovery was started but did not finish.
  
• Recover Error   Contains an error code if recovery was started but encountered an error and could not finish.
  
• Recover Time   Displays either the time when the Restore.env file was created or the last time recovery started but did not finish.
  

When you restore an Exchange 2000 Server database, you have the option to indicate that the restore procedure that you are performing is the last restore procedure you will perform before you mount the database. This option is enabled by selecting the Last Backup Set check box after you click the Start Restore button on the Restore tab in Microsoft Windows® 2000 Backup.

When you restore an online backup of an Exchange 2000 Server database, the database is in an inconsistent state. The process of bringing the database to a consistent state after a restore procedure is called hard recovery. During hard recovery, the Extensible Storage Engine (ESE) uses information in the log files and patch files, for Exchange 2000 Server versions earlier than SP2, to redo operations performed on the database, and then to undo any operations that belong to incomplete transactions.

In Exchange Server 5.5 or earlier, this happens automatically the next time the service starts. When the service starts, the presence of a Restore in Progress registry key indicates that recovery must be run on the database using the information in the Restore in Progress key.

In Exchange 2000 Server, hard recovery is no longer controlled by the Restore in Progress key. It is controlled by a file called Restore.env that is created in the folder that you specify during the restore process in the Temporary location for log and patch files box. This folder will also contain the log files and, in case of Exchange 2000 Server versions earlier than SP2, patch (.pat) files necessary to complete recovery on the database.

The Last Backup Set check box in Windows 2000 Backup determines if hard recovery should be run after the backup completes. If you select this check box, hard recovery is run automatically after the restore procedure finishes, and then the temporary files are removed. At this point, you can mount the database. If you do not select this check box, hard recovery is not run. After the database files and temporary files are copied to disk, the restore procedure finishes. If you attempt to mount the database at this point, you will not be able to.

The purpose of the Last Backup Set option is to allow you to restore a full backup, and then restore one or more incremental backups or a differential backup. You only select this check box during the last restore procedure, because you do not want hard recovery to run until all the log files to be recovered are in place.

For example, if you are restoring an Exchange 2000 Server database from a full backup and two incremental backups, clear the Last Backup Set check box when you restore the full and the first incremental backups. Select the Last Backup Set check box only for the last incremental backup.

In certain circumstances, you may not want to run hard recovery immediately after the restore procedure. Also, you may forget to select the Last Backup Set check box during the last restore procedure. For these reasons, you can manually run hard recovery using Exchange Server Database Utilities (Eseutil).

Use the following command to manually run hard recovery.

  eseutil /cc <path to directory containing the Restore.env file>

For example, if the path specified in the Temporary location for log and patch files box during the restore procedure is C:\TempRest, the command to run hard recovery is the following.

  eseutil /cc c:\temprest

If you run the eseutil /cc command, the command may not work with Exchange 2000 Server running on a cluster server.

This problem can occur if Eseutil is using the local computer name instead of the cluster name.

To work around this problem, set the following environment variable:

SET _CLUSTER_NETWORK_NAME_=<cluster_name>

For example, in a two-node cluster that is composed of SERVER1 and SERVER2, with the cluster visible to network clients as CLUSTER1, type the following command.

SET _CLUSTER_NETWORK_NAME_ =CLUSTER1

Setup.exe /disasterrecovery allows you to recover from missing files, registry keys, and deleted folders on Exchange 2000 Server. You must make sure that there is a valid backup of the data, and if not, check to make sure the databases that are located on the server are consistent.

Setup copies the information from the Active Directory® directory service-stored information, and then registers the same components that existed on this server before the problem that caused loss of data on the server. After Setup with the /disasterrecovery switch finishes installing the Exchange 2000 Server binary files, the stores do not automatically mount because Setup expects your databases to be restored. After you restore the public store or the mailbox stores, you can mount them.

For the following reasons, you may use a disaster recovery setup by running the command, setup.exe /disasterrecovery:

• If one or more Exchange folders have been deleted accidentally, for example, the \Bin folder.
  
• If MSExchange registry keys are deleted and there is no backup of the registry available.
  
• In case you need to replace hardware running Exchange 2000 Server.
  

For a successful disaster recovery, you must make sure to choose the same components for disaster recovery that are installed on the server you want to recover. Additionally, because Setup will read the information from Active Directory, you should make sure that the drive configuration is the same on the server as it was before the problem you are recovering from. Paths to Exchange 2000 Server databases are stored in Active Directory. If the drive configuration is different, Active Directory might point to invalid paths, drives that do not exist, which will cause problems.

After Exchange 2000 Server SP2 is installed, you might notice a log called E0xtmp.log in the folder that holds Exchange transaction logs. The x in the name of the log will be replaced with the number of the storage group that this log belongs to, for example E00tmp.log or E01tmp.log.

In all versions of Exchange 2000 Server, the E0xtmp.log file is empty. You can safely ignore it. Exchange 2000 Server automatically deletes the file when all stores in one storage group are dismounted appropriately. The E0xtmp.log file is not backed up to the tape during an online backup of Exchange 2000 Server storage groups.

In versions earlier than Exchange 2000 Server SP2, this log was also used. SP2 changed the timing when the file is generated, so it is more visible on the disk. For more information, see the For More Information section.

For more information, see the following Exchange Server resource and Microsoft Knowledge Base articles:

• Mailbox Recovery for Microsoft Exchange 2000 Server
  
• 232922, "XADM: How Log Files Are Replayed During Exchange 2000 Server Restore Procedure"
  
• 253914, "XADM: How to View the Contents of the Restore.env File"
  
• 266689, "XADM: The "ESEUTIL /CC" Command Does Not Work on Cluster Server"
  
• 232932, "XADM: There Is No RestoreInProgress Registry Key in Microsoft Exchange 2000 Server"
  
• 232938, "The "Last Backup Set" check box and hard recovery in Exchange"
  
• 298068, "Exchange setup "Server object ... already exists" error message"
  
• 316794, "XADM: Exchange 2000 SP2 Does Not Allow You to Restore Exchange 2000 or Exchange 2000 SP1"
  
• 319785, "XADM: New E0Xtmp.log Behavior After You Apply Exchange 2000 SP2"
  
• 240152, "How to determine which edition of Exchange Server is installed"