The following is tip #20 from "20 tips on protecting and recovering Exchange data in 20 minutes," excerpted from the book, "Mission Critical Microsoft Exchange 2003" (Digital Press, a division of Elsevier, Copyright 2004). For more information about this book and other computing titles, please click here. Return to the main page for more tips on this topic.
These steps in using Exchange recovery servers may seem a bit cumbersome. That's because they are! Microsoft has done a great job of documenting this procedure for recovering mailboxes and data, but it is very complex and somewhat prone to error.
In fact, Microsoft Product Support Services (PSS) spend far too many cycles support Exchange recovery server methods. In response, the Exchange development team has heard the cries of Exchange administrators (and PSS support engineers) and has devised a method for providing this functionality in a much simpler and easier to deploy mechanism. It is my pleasure to introduce you to the Exchange Server 2003 Recovery Storage Group (RSG)!
Bringing greater flexibility to the recovery of databases, mailboxes and individual items, the Exchange Server 2003 RSG is a powerful new feature. The RSG is a special-purpose fifth storage group available on Exchange Server 2003 servers that exists alongside your production storage groups on the server. This means that even though a server is configured with four production storage groups, you can still add an RSG to the server. You can then use this RSG to recover databases from any Exchange Server 2000 SP3 and later server that is in the same Administrative Group as the server with the RSG. After you have recovered a database to the RSG, the use and procedure for recovering mailbox data is much the same as the Exchange 2000 recovery server scenario. You can use tools such as ExMerge to move data from the RSG to production storage groups. This allows you to recover an entire database or just a single mailbox.
The RSG does have some caveats, however. You can only have one RSG per server, and the RSG does take overhead on the server. In addition, if you want to perform concurrent recovery operations on the server and have the maximum number (four) of storage groups and an RSG configured, you will not be able to do so (since a maximum of five ESE instances are possible per Exchange 2000/2003 server, there are no available instances to perform concurrent operations). Finally, RSGs only support the recovery of mailbox stores -- not public folder stores (see Table 5.3 for more information). RSGs are created the same way you create regular storage groups by selecting the server and right-clicking and choosing New -- Recovery Storage Group. (Yes, it is that simple!)
The concept of an RSG is new to Exchange Server 2003 and promises to save Exchange administrators and Microsoft PSS hours of work. By avoiding the requirement to set up an entire recovery forest and deploy extra hardware and software (which, by the way, Microsoft required you to pay for), RSG offer huge wins. However, time will attest to the success of the RSG and whether the efforts the Exchange development team were well invested. If you have ever struggled or been frustrated with the old way of doing things (Recovery Servers), Exchange Server 2003's Recovery Storage Group is a welcome relief.
|Exchange 2003 Recovery Storage Group Usage Scenarios Scenario||Usage Description|
|Database/mailbox/item recovery||Useful for recovery of lost or deleted data from user mailbox. A database from the same Administrative Group as the RSG can be recovered and data can be extracted via tools such as ExMerge.|
|Rapid recovery||In the event of a catastrophic loss of a mailbox database, a "stub" mailbox database can be created and the logs copied to alternate location. The RSG can then be used to recover the database to the point of failure while the stub database allows continued service for users. Once the database has been recovered, it can be swapped with the stub database and new data from the stub database can be recovered via the RSG to the original production database.|
Power with responsibility
With the advent of multiple storage groups and databases in Exchange 2000/2003, the recovery API was stretched to accommodate new scenarios. You must be able to perform backup and restore operations for the entire server, a storage group, or an individual database.
In addition, since these operations can be performed concurrently, ESE must be able to handle this as well. Exchange 2000/2003 offers a great deal of flexibility and additional availability that previous versions did not offer. For example, you could have four databases configured that each host 1,000 users (a total of 4,000 users). You begin restore operations for one storage group or database without impacting the other storage groups.
In our example, 3,000 users would be on-line accessing their data while the 1,000 users using the database being restored would be the only affected users. This, indeed, gives operators many more options and reduces the overall impact of restore operations. However, it also complicates procedures, requires better training, and has greater potential for error. Gather the knowledge you require to ensure that you are implementing solid disaster-recovery plans for Exchange servers. Understand the different backup strategies available for Exchange 2000/2003, and select the one that best suits your organization. Also, be sure to investigate how you can leverage Exchange Server 2003's RSG feature. Finally, keep an eye on Exchange 2003's support for Windows VSS and the result vendor solutions that become available. Also, stay tuned because many of the best practices and tricks of the trade for Exchange 2003 have not been discovered yet (although things aren't that different from Exchange 2000). The power of Exchange 2000/2003 storage must not be realized without properly understanding the disaster-recovery implications of your storage design choices.
Get more "20 tips on protecting and recovering Exchange data in 20 minutes." Return to the main page.
About the author: Jerry Cochran is a contributing editor for Windows IT Pro and Exchange & Outlook Administrator and a group program manager for Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital Press).