Best Practices for Recovery Storage Groups and Exchange Server 2003

As you know, a Recovery Storage Group (RSG) in Microsoft Exchange Server 2003 lets you restore a single mailbox (brick-level restore) without having to perform an individual mailbox backup (brick-level backup). An RSG supports both Exchange 2000 Server Service Pack 3 (SP3) and Exchange 2003 databases; however, you need to perform the restore on a server running Exchange 2003. Most backup programs like Symantec's Backup Exec with its Exchange Agent let you perform an individual mailbox backup, however the mailbox backup uses Messaging API (MAPI) to back up mailboxes, and as a result, performance suffers. On a typical backup with a fast tape drive, you might see 600mbps backup rates on the Exchange databases, but when the mailboxes are backed up with MAPI the rate can drop below 100mbps. If you have a relatively small Exchange database, this rate isn't a problem, but for most companies running Exchange Enterprise 2003, there usually isn't enough time to perform a brick-level backup.

Exchange Enterprise lets you have four storage groups (SGs) with five databases in each SG. For larger installations, I suggest you create multiple SGs and databases to keep the individual Exchange databases to a manageable size (less than 50GB). The downside of having multiple smaller databases is that you have more disk contention and slightly slower performance. This is especially true on a SAN unless you can dedicate an entire array to each Exchange database. But the advantages of having multiple Exchange databases are many: faster RSG restore times, shorter run times when using Eseutil to defragment or repair a corrupt database, less disk space required and faster copy times when you want to copy an Exchange database to another location before running Eseutil, and less chance of database corruption.

I've seen quite a few excellent articles about using an RSG to restore a single mailbox, but I haven't seen any that summarize the pitfalls of using an RSG. You typically don't perform an RSG restore on a regular basis--maybe once a month--so you can easily forget the process of using an RSG. I suggest you create internal RSG documentation to refresh your memory when you need to restore a single mailbox. Here are some tips I've found useful when using RSGs.

- RSGs don't support Public Folders.
- Use the latest version of Exmerge. As of this article, the latest version of Exmerge is 06.05.7529. You can download it from http://www.microsoft.com/downloads/details.aspx?FamilyID=429163ec-dcdf-47dc-96da-1c12d67327d5&displaylang=en.
- Create the RSG ahead of time, but don't create databases in the RSG until you are ready to perform a restore.
- Create the RSG databases only when you need to perform a mailbox restore, and create the RSG database target location in a different folder than your live databases.
- Before you start the RSG database restore, make sure any previously restored database and log folders are empty. This will prevent database-mounting problems after the restore is completed.
- After you run Exmerge and extract the necessary mailbox information, delete the database you just restored. This step is important! When you create a database within the RSG, any database restores are automatically redirected to the database in the RSG. Usually this is the desired behavior because you don't want to restore the database to the live folder. You can make a registry modification to change this behavior, although I don't recommend it. If you forget that you made this registry change, the next time you perform an RSG restore, you'll overwrite the live database, which can cause serious problems. If you don't delete the RSG database after you've used it and you do want to restore over a live database, it will be redirected to the RSG store and it will be difficult to determine why your restore didn't successfully complete. Save yourself a lot of grief and delete the RSG database after you've finished using it. You must delete the database using both the Exchange System Manager (ESM), and Windows Explorer. Deleting the database in the ESM doesn't delete the actual database and log files; you must use Windows Explorer to manually delete these files.
- You might receive an error C1041724 after you complete the database restore of an RSG. A common cause of this error is not verifying that the target folders were empty before performing the restore. If you leave the log files on the server from a previous RSG restore, these log files are run against the current RSG database, which can cause database-mounting problems. Make sure your target folders are empty prior to the restore.

RSG is a powerful tool in any Exchange Administrator's toolbox. With a fast tape drive and relatively small database, you can easily restore a single mailbox within an hour. Make sure to delete the databases and log files after you complete the mailbox restore.

Tip

Running a VPN? Make sure to use at least 3DES (or Advanced Encryption Standard--AES) for your encryption. DES is cryptographically weak and can be cracked. Consider using a certificate instead of a shared secret to increase your VPN security.