Overview of the Database Restore Process

 

When a restore operation begins, Backup informs the ESE that the process has begun, causing ESE to enter restore mode. The database (made up of a pair of files: an .edb file and an .stm file ) is then copied from the backup media directly to the database target path. The associated log files are copied to a temporary folder, and a separate instance of ESE is started to replay the transaction logs from their temporary location into the restored database.

The restore process creates the Restore.env file, which keeps track of the storage group that the database belongs to, the paths of the database files when they were backed up, the path to the database when they were restored, the range of log files that were restored, and other pertinent data.

You must restore a full backup set (either a normal or copy backup) before you can restore a differential or incremental backup set. This is because restoring a full backup set creates the Restore.env file. Restoring a differential or incremental backup set only updates the Restore.env file; it does not create one. If the Restore.env file does not exist, the differential or incremental updates cannot restore.

Always use different temporary folders for each full backup set that you are restoring. For example, if you were to restore two normal backups to the same temporary folder the second Restore.env file that would be created would overwrite the first Restore.env file. Therefore, always specify a different temporary folder for each normal or copy backup set that you are restoring.

However, when you restore an incremental or differential backup, specify the same temporary folder you used for the full backup that the incremental or differential backup belongs with, so that they are paired with the correct Restore.env file.

After the database files are copied back to their original locations and the Restore.env and transaction log files have been copied to the temporary folder, ESE initiates a hard recovery to replay log files into the database. This brings the database up-to-date with the time that it was lost if all the log files since the backup was taken are available. First, Restore.env is used to determine which transaction logs will be played from the temporary folder. Then, if it is possible, additional transaction logs from the target storage group are also replayed.

Following hard recovery, the temporary instance of ESE is stopped. If you select the Mount Database After Restore check box in Backup, the newly restored database is automatically mounted in the target storage group.

The following figure illustrates the Exchange restore process.

The flow of the Exchange restore process