We're updating our disaster-recovery procedures before deploying Exchange Server 2003. Now that we can use Exchange 2003's Recovery Storage Groups, what's the best way to use them for recovery?
The Recovery Storage Group feature lets you quickly offer dial-tone service for one or more databases in your Exchange organization. Imagine that a mail database gets corrupted and can't be mounted. You can quickly bring up a blank database that your users can log on to and send and receive mail while you fix the old database and recover the users' stored mail data. However, a problem arises when you're finished restoring the old database: How do you preserve the mail that users sent and received on the new database? Recovery Storage Groups offer a straightforward way to address this problem because you can use them to mount any database from any server anywhere in an administrative group. The overall steps to this process are as follows:
- When the mailbox database fails, dismount it and move its files (including the transaction logs) to a location in which they won't be rewritten.
- Create a new, blank database with the same name as the failed database (we'll call this the dial-tone database). Connect users to the database so they can begin using it.
- Copy all the transaction logs for the failed database's storage group to a location in which they won't be overwritten.
- If you haven't already done so, create a Recovery Storage Group by using the same disk volume you used to create the dial-tone database.
- Move the transaction logs from Step 3 to the Recovery Storage Group's folder.
- Restore the backup of the corrupted database to the Recovery Storage Group. Because the logs are already in the appropriate folder, the Store will be able to replay the logs when you mount the database from the Recovery Storage Group. This step will restore the Recovery Storage Group to the point of failure.
- Dismount the recovered database.
- Dismount the dial-tone database.
- Swap the .edb and .stm files for the dial-tone and recovered databases. This step has the effect of putting the recovered database back where it originally was, while simultaneously putting the dial-tone database in the Recovery Storage Group.
- Mount both databases. At this point, users have their original mailboxes back, with no access to mail they created during the recovery.
- Use the ExMerge utility to move mail from the dial-tone database back to the original database.
Step 11 is slightly counterintuitive because it might seem easier to use ExMerge to move data from the recovered database (which starts off in the Recovery Storage Group) to the dial-tone database. However, performing these steps in the order I've described is faster because less data resides in the dial-tone database and it preserves the users' delegates and rules. Because this process is complex, it's crucial that you test it before you attempt it in a production environment.
