Export (0) Print
Expand All

Recovering an Exchange Database

 

Topic Last Modified: 2006-01-31

Exchange Database Recovery Checklist

 

__

Dismount the databases for each mailbox or public folder store that you are restoring.

__

Configure the databases so that the restore can overwrite them (optional).

__

Determine the database and log file locations of the files that you are restoring (optional).

__

Copy the current database files to another location (optional).

__

Make sure that the mailbox and public folder store names in Exchange System Manager match your backup media.

__

Make sure that the Microsoft Exchange Information Store service (MSExchangeIS) is running.

__

Select the backup files that you want to restore from your backup media.

__

Restore the selected files.

__

Make sure that the restore process was successful.

__

Replay the transaction log files (Eseutil /cc) (optional).

__

Mount the databases (stores).

Before you perform the restore process, you must dismount the Exchange databases that you want to restore. If a database that you try to restore is still mounted, the restore process will fail. For detailed instructions, see How to Dismount Mailbox and Public Folder Stores.

noteNote:
When mailboxes and public folders are dismounted, they are inaccessible to users. Because Exchange supports multiple storage groups and multiple mailbox and public folder stores, you must dismount only the databases that are being restored from your backup. To restore a database without affecting e-mail users who have mailboxes on that database, consider using a recovery storage group instead of its original storage group, Typically, recovery storage groups are used only when you want to extract or merge specific data from the backup database to the original still running database.
noteNote:
You must dismount every database that you want to restore.

To ensure that the restore process overwrites Exchange databases, you must configure the databases that are being restored. However, you do not have to configure the databases if you restore them to their original locations, or if you use recovery storage groups. It is only required when the databases that you restore have different GUIDs in Active Directory. For example, a different GUID is required when you restore a database to another forest, such as a test forest. A different GUID is also required if the Active Directory object for the database has been deleted. When you re-create deleted objects in Active Directory, you give each object a new GUID.

Unless you know that you must overwrite the database, do not use this option.

For detailed instructions, see How to Configure the Exchange Databases so That the Restore Process Overwrites Them.

If you plan to make copies of the damaged database so that you can try to repair it later if necessary, you determine the location of the database and log files so that you can move or copy them.

In the following procedure, you must record information from the properties dialog boxes from both the database and the storage group that contains the database. You must do this for each database you want to move or copy. For detailed instructions, see How to Determine the Database and Log File Locations of the Files You Are Restoring.

You can preserve the existing database files before they are overwritten by a restore in case the restore process is unsuccessful. Keeping a copy of the damaged database files allows for more recovery options. For example, if your restore is unsuccessful, a copy of these files helps you to revert to the original versions, which might be repairable.

The disadvantage of copying the database files before the restore is that it might add significant time to the database recovery process. If moving the files to another location on the same logical drive is an option, this will be much quicker than trying to copy the files. For detailed instructions, see How to Copy or Move the Existing Versions of the Database Files You Are Restoring.

importantImportant:
Moving database files from their original location to a different folder on the same logical disk is almost instantaneous, as the only data that must be written to disk is an update to the NTFS Master File Table (MFT). Moving the files to a different logical disk (even if both drives share the same physical disk) or making a copy of them in any location takes much longer because each database file must be rewritten to the new location. Moving or copying the database files to a different location over the network takes even more time, and can use a lot of your network bandwidth. This is just one reason why making full use of the 4 storage group and 20 database capabilities of Exchange Server 2003 (more databases of smaller sizes) is actually more manageable and can decrease the time that you spend on backup and restore-related tasks.

The names of the storage groups and databases (mailbox stores or public folder stores) that you restore from your backup media must match the names of the storage groups and databases as they exist as objects in Active Directory for the server to which they are being restored. If Exchange System Manager is running on any Exchange server in the organization, it will read this data from Active Directory and display it so that the data can be verified against the names of the storage groups and databases as they appear in your backup. If the names do not match, the restore process fails.

For example, if you delete a storage group and its databases before you try to restore them, the storage group and its database will not exist in Active Directory for that server, and you must re-create a storage group and databases with names that exactly match the storage group and database names on your backup media. For detailed instructions, see How to Ensure that Storage Group and Database Display Names Match the Names of the Files You Are Restoring.

If, after you follow the procedures earlier in this chapter, you find that the names do not match, you must create storage group and databases that match the names of the storage group and databases that you are restoring from backup.

In the case where a database or storage group name has changed, you only have to rename the database or storage group.

In situations where you are setting up a new server, or the database or storage group is missing, you have to create them. For detailed instructions, see the following procedures:

In cases where you are restoring differential and incremental backups, make sure to restore the backups in chronological order. Always restore the normal backup first, and then restore any incremental or differential backups in chronological order. If you restore backup sets out of order, some transaction logs might not be replayed. For detailed instructions, see How to Restore Selected Files.

The Status field in the Restore Progress dialog box indicates where Backup is in the restore process. If the status field reads Failed, there were problems with the restore process that must be resolved before you can continue restoring your Exchange database. Click the Report button for more information about these errors.

If the Status field reads Completed, Backup has successfully restored the database and the log files have been restored to the temporary directory. However, the transaction logs must still be replayed for the whole recovery process to complete. Transaction log replay can take several hours to complete.

For more information about how to check the success of the restore process, see "Checking the Success of a Completed Restore Job" in Using Backup to Restore Your Data.

When a database is restored from backup media, it is in what is referred to as an inconsistent state where the database and log files are not synched together. To fully recover your Exchange data after you restore the database, you must replay the transaction logs to bring the database up-to-date or make it consistent.

Hard recovery is the process that brings a restored database back to a consistent state. To initiate hard recovery, you can select the Last Restore Set check box in Backup when you restore your last database or you can use the Eseutil /cc command.

To run Eseutil from any command prompt, follow the procedure in "Running Exchange Tools Globally on a Server" earlier in this chapter.

It is recommended that you run only one instance of Eseutil /cc at a time, even if you restore multiple databases concurrently. For detailed instructions, see How to Run Eseutil /cc.

Mounting the store is the last step in recovering an Exchange database. Before you mount the store, make sure that the hard recovery is completed. To make sure that the hard recovery is completed, check whether the Restore.env file has been deleted. Restore.env is not deleted until the hard recovery succeeds. Open the folder that you designated as the temporary location for log files, and then open the folder for the storage group that you are restoring. If the Restore.env file is still there, the hard recovery is not completed. Do not try to mount the store.

noteNote:
If you have performed hard recovery with the /k switch, which prevents deletion of Restore.env (Eseutil /cc /k), check the database header for a clean shutdown state by using Eseutil /mh.

After you are sure that the transaction log replay is completed, mount each store that you have recovered. For detailed instructions, see How to Mount an Exchange Store.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft