Recovering a Mailbox Database Using a Dial Tone Database in Exchange Server 2003
If you have a large Exchange database, it can take several hours to restore it from backup after a disaster. However, by implementing a recovery strategy called Messaging Dial Tone, you can restore e-mail service more quickly to users (providing them with a basic "dial tone") and then restore users' previous data as it becomes available.
With Microsoft Exchange Server 2003 Service Pack 1 (SP1), you no longer need to use ExMerge to move recovered mailbox data from the recovery storage group to the regular storage group after you have restored a mailbox store to the recovery storage group. The Recover Mailbox Data feature in Exchange 2003 SP1 Exchange System Manager replaces ExMerge in the majority of recovery cases. For more information about the Recover Mailbox Data feature in Exchange 2003 SP1, see Exchange Server 2003 SP1 Recover Mailbox Data Feature.
Details about the Messaging Dial Tone strategy are provided later in this topic; the basic process is as follows:
Set user expectations for the functionality that will be available to them and how soon full functionality will be restored.
Create the dial tone database.
This step involves resetting the damaged Exchange database by removing the current database files from the storage group directory. Keep copies of the files in case they are needed later. Microsoft® Exchange Server 2003 re-creates blank database files to replace the files that you removed. When users attempt to access their mailboxes, Exchange creates new mailboxes in the database, and the users are able to send and receive mail. Because the user objects retain their original Exchange attributes (including msExchMailboxGUID), the new mailboxes have the same GUID values as the old mailboxes. Later, this fact allows ExMerge to successfully transfer data between the original database (which will be running in the recovery storage group) and this temporary "dial tone" database.
When you reset a database, you lose not only all messages, but also all rules, forms, views, and other mailbox metadata. For more information about the end user configuration information that is lost when resetting a database, see Microsoft Knowledge Base article 282496, "XADM: Considerations and Best Practices When Resetting an Exchange Mailbox Database." This information will be recovered during the merge process if you merge the recovered data into the original database as described in this section.
During the first two steps of Messaging Dial Tone recovery, the dial tone database provides service for users while you recover the damaged database
Configure the recovery storage group and the recovery storage group database.
For best results, place the recovery storage group database on the same logical drive as the dial tone database. As a result, moving even large files between folders on the same drive (as you will do later) is almost instantaneous.
Restore or repair the original database in the recovery storage group (see the figure above).
After you have completed the necessary recovery on the recovery storage group database, you can disconnect from both databases and swap the database files between the original storage group and the recovery storage group (see the following figure).
After swapping the dial tone database into the recovery storage group and the original database back to its original storage group, users can access their previous data (including rules, forms, and offline or cached mode data files), but they cannot access new items.
After you swap the two databases, users gain access to previous data
Use ExMerge to merge data from the dial tone database back into the original database. This brings the user mailboxes up-to-date (see the following figure).
Use Mailbox Merge to bring the recovered mailboxes up-to-date with content that was created during the restore and recovery process
This recovery strategy is feasible in earlier versions of Exchange, but it requires building a separate Exchange recovery server and then copying large amounts of data back and forth across the network. By using the recovery storage group, you can avoid building an extra server and, if you keep all databases on the same drive, eliminate the time needed to copy large files between disks and servers. This approach can cut several hours from your recovery time.