Exchange 2003 Recovery Storage Group

Introduction

As I run into various problems and/or tasks on the job site, I like to document some of the things I have learned. This essentially is why this blog exists. My hope is that by posting a comprehensive "how to" of common tasks, that we IT Professionals run into on a daily basis, I just might help someone solve a problem a little bit faster in the future.

Today I will touch on some of the things I learned recently using the Recovery Storage Group option available in Exchange 2003. I have worked on Exchange 2003 for many years and have actually never had to perform this procedure until recently. My primary means of backup was through a brick-level backup agent used with many of the popular backup solutions. However, due to time constraints with the current backup window a client of mine was performing Information Store backups only. A user then complained that a number of his folders had gone missing. The usual check to the Deleted Items folder and also the "secret" server-side Deleted Items folder proved unsuccessful. We had good backups using Backup Exec 10.0 of the Information Store, so now was the time to use the Recovery Storage Group option.

Instructions

The Recovery Storage Group is actually quite simple to setup, however, throughout the whole process I was worried about whether I was going to interrupt the live environment and take down the email system. If everything is done correctly, this should not happen. Also, throughout the process I was always worried that I was somehow going to "overwrite" the current database with my backup instead of sending the backup to the Recovery Storage Group.

This Microsoft KB Article explains explains just about everything you need to know about the Recovery Storage Group (http://support.microsoft.com/kb/824126). For simplicity, we will say that the Recovery Storage Group is more of a staging area. Clients cannot connect to it directly. You cannot send or receive mail with it. It is simply used to mount and access a restored database.

Creating the Recovery Storage Group is actually quite simple. First, go into the Exchange System Manager and drill down to Adminstrative Groups > First Administrative Group > Servers > YourServerName. Right-click on the server and select New > Recovery Storage Group.

Give your group a name and then you are ready to add the database you are looking to recover. You can do this by right-clicking on the newly created storage group and selecting the Add Database to Recover... option.

Next you will be given a window with the databases that are available for recovery. Many of you will only see a single database. Select this database and continue on. Also, you will be prompted in this process to name the location where the database will reside. Select a folder that has enough space to hold the newly restored database. In my case, the currently mounted live database was about 120GB. Fortunately, I had a local disk with about 150GB free, so I elected to place the database in a folder on this drive. Make sure you have enough disk space or the restore operation will fail.

Now we are ready to move onto the restore portion from the backup software. This particular client was running Backup Exec 10.0. I created a job to restore the database from a date that I knew had the data the client wanted. My main concern through all of this was the fact that I never was able to "tell" Backup Exec to restore or redirect the database restore to the Recovery Storage Group. This was because you don't need to. When the RSG is created, the Exchange backup API's will "stand in" and redirect the backup to the Recovery Storage Group. Also, if you are concerned with overwriting the live production database, make sure the following option is checked by viewing the Properties of the Mailbox Store in question. Under the Database tab make sure the option of "This database can be overwritten by a restore" is not checked.

Note: As I attempted to perform this restore I received several errors from my backup job. I ensured that everything was setup up properly and it was. However, despite repeated efforts to start the restore I was unsuccessful. It wasn't until I started an Information Store backup that I was able to perform the restore. I simply cancelled the job immediately after I determined that it was properly backing up Exchange. I did not investigate this any further, but I want to mention this to anyone else that may be experiencing the same problem. There may have been issues with Backup Exec trying to communicate with the newly created Storage Group. By backing up the existing Information Store, the Exchange server and or Backup Exec server may have aligned itself properly to allow the restore to job to start running.

Now for the backup job itself. Since I was performing this restore after hours, I did not check the "Commit After Restore Completes" option in Backup Exec.

I left for the night and came back the next morning unable to mount the newly restored database. The errors I received were the following.

Event Type: ErrorEvent
Source: ESEEvent
Category: Logging/Recovery
Event ID: 619
Date: 9/10/2007
Time: 12:43:58 PM
User: N/A
Computer: SERVERNAME

Description:Information Store (3020) Recovery Storage Group: Attempted to attach database 'M:\Exchdata\Recovery\Mailbox Store.edb' but it is a database restored from a backup set on which hard recovery was not started or did not complete successfully.

Event Type: ErrorEvent
Source: MSExchangeISEvent
Category: General
Event ID: 9519
Date: 9/10/2007
Time: 12:43:58 PM
User: N/A
Computer: SERVERNAME

Description:Error 0xfffffde0 starting database "Recovery Storage Group\Mailbox Store" on the Microsoft Exchange Information Store.

This was simply due to the fact that the hard recovery had not been completed. Backup Exec will do this for you if the above mentioned option is selected. If it was not selected you can manually run this by using the eseutil. A KB article written by Symantec explains this in much greater detail (http://seer.support.veritas.com/docs/245494.htm).

My command looked like the following (with the quotes):

Eseutil /cc "C:\Temp\First Storage Group"

I was now able to use ExMerge to access the old user data. Simply download and start the program. You will be prompted to choose a domain controller to connect to and then soon you will see a scree to select which storage group you would like to connect to. Once selected, you can dump out the mailbox information into a PST and then use Outlook to restore what you need.

Once you are done, it is best practice to delete and remove the Recovery Storage Group.

Conclusion

With a few simple steps and some patience, it is quite simple to mount a backed up database through a restore to the RSG. In some organizations this may be your only form of backup. If your organization has the tape size and time window to do it, then I recommend performing a "brick-level" backup of Exchange. Restores of individual items and mailboxes can be completed much quicker and easier.