Working With Exchange 2010 Recovery Databases

Background
Brien Posey has an excellent post explaining the steps required to mount a recovery database in Exchange 2010. His post can be found here. While assisting one of my customers restore email data using a recovery database, I learned some lessons that I thought I’d share. In this instance, my customer needed to restore data from a backup created using NetBackup. The customer initially tried to use NetBackup’s granular restore technology to recover the data in question but they were unsuccessful. I suggested restoring the entire database to an Exchange 2010 Recovery Database and that’s when I learned documenting the steps we followed might prove helpful to others.
Restore the Database
It’s important to note that since we couldn’t make use of NetBackup’s granular restore technology, our only remaining option was to restore the entire database file and then find a way to mount the database as an Exchange 2010 Recovery Database. NetBackup’s high level instructions to using an Exchange 2010 Recovery Database are similar to the following:

1. Use Exchange 2010 Management Shell to create a Recovery Database
2. Leave the Recovery Database dismounted
3. Use NetBackup to perform the database restore

NetBackup’s instructions for performing restores using granular restore technology are much more thorough than their instructions for using Exchange 2010 Recovery Databases, so some trial and error was required in order to get to our data. Initially, I created a recovery database using the following PowerShell command:
New-MailboxDatabase -Recovery -Name “RecoveryDatabase” -Server MailServer1 -EdbFilePath “D:RecoveryDatabaseDatabaseRecoveryDatabase.edb” -LogFolderPath “D:RecoveryDatabaseLogs”
Then we used NetBackup to restore the database file. I then went to mount the recovery database and received the following message:
At least one of this store’s database files is missing. Mounting the store will force the creation of an empty database.
The dialogue box containing the error is below:

This seemed strange to me until I realized what was actually happening. The name of the database we restored using NetBackup was called DB2.edb, yet the database I created with my PowerShell command noted above was RecoveryDatabase.edb. Exchange was behaving normally and was simply informing me that it was about to mount the empty database that I had created. To validate my suspicion, I mounted the database and sure enough, Exchange generated all the necessary log files and created an empty Exchange database called RecoveryDatabase.edb. While I was able to get the recovery database mounted, this got us nowhere closer to our goal of mounting a recovery database that actually contains data.
Lesson Learned: When using PowerShell to create your recovery database, make sure to create your database using the exact name of the database you need to restore.
The following is the PowerShell command I should have used initially – notice the name of the .edb file generated using the –EdbFilePath switch:
New-MailboxDatabase -Recovery -Name “RecoveryDatabase” -Server MailServer1 -EdbFilePath “D:RecoveryDatabaseDatabaseDB2.edb” -LogFolderPath “D:RecoveryDatabaseLogs”
Mount the Database
After creating the recovery database with the proper –EdbFilePath switch, I still couldn’t mount the database because it was in a “dirty shutdown” state. I typed the following command to validate the database’s state:
eseutil /mh DB2.edb
The output of the command above returns a lot of data, I snipped the relevant portion of the output and placed it below:

The recovery database won’t mount until its state is listed as ‘Clean Shutdown‘. With no log files, performing a software recovery was not possible. Therefore I had to resort to our old friend, eseutil. I ran the following eseutil command to perform a hard recovery of the restored database:
eseutil /p DB2.edb /t:D:RecoveryDatabaseDatabasetmpRepair.edb
Note that I always use the /t parameter to specify the location of the temporary database that gets created when using eseutil with the /p parameter. Remember that eseutil /p creates another copy of the database you are running your command against, and remember that you will need adequate disk space for the eseutil command to complete successfully. For example, if your database is 100GB, you will need 110GB of free disk space for the eseutil command to complete. This is because eseutil sequentially writes data to a new database, deletes the old database, renames the new database with the name of the old database, and places the new database in the same file location as the old database. Also note that there is no space between the /t: and the directory location so that’s not a typo that you’re seeing. Since the first time I used eseutil on an Exchange 5.5 database, the /t parameter has always worked in that fashion. One last thing I’ll mention about the eseutil command, if you fail to specify a temporary directory when using the /p parameter, eseutil by default will place the temporary database file on the C: drive of your mailbox server. This can have disastrous ramifications if you run out of disk space on the C: drive of your mailbox server so make sure you take disk space into consideration before using eseutil with the /p parameter.
My database was 150GB so I was a little concerned how long the hard recovery process would take. Back in the day (2000 and 2003) eseutil could process about 4GB/hour. I have seen published statistics stating that the version of eseutil built into Exchange 2010 can process approximately 45GB/hour. My hard recovery completed in about 2.5 hours so the eseutil statistics I’ve seen seem about right. Once complete, I ran the following command again to validate that state of the database:
eseutil /mh DB2.edb
This time the state of my database changed to ‘Clean Shutdown‘ as you can see below:

Now that my recovery database was in a clean shutdown state, I was able to proceed with mounting it.
Validate Database Contains Relevant Data
After mounting the recovery database, I then entered the following command to validate that the user account data I needed was there:
Get-MailboxStatistics -Database RecoveryDatabase
To refine your search when validating your database content, try filtering such as in the following:
Get-MailboxStatistics -Database RecoveryDatabase | Where {$_.DisplayName -eq “1234, Test”}
The above command returned the following data:

Restore Email Data
For this recovery, my customer wanted the contents of the restored data to be exported to a PST file. Alas, if only it was possible to export mailbox content from an Exchange 2010 Recovery Database directly to a PST file. Sadly, that is not possible. In order to accomplish this goal, a two-step process is required. First, the contents of the mailbox data in the recovery database must be restored into a production mailbox. After the data is restored to a production mailbox, then the data can be exported to a PST file. To accomplish the first step, I simply created a temporary mailbox for this purpose and executed the following command:
Restore-Mailbox -RecoveryMailbox “1234, test” -Identity ex2010 -RecoveryDatabase RecoveryDatabase -TargetFolder “RecoveredItems” -StartDate 1/1/2010 -EndDate 12/31/2010
A few things to note about the command above:
First off, the source and target mailboxes can get a little confusing. Think of the Recovery-Mailbox as the source mailbox, and the Identity mailbox as the target mailbox. When entering my command, the contents of test1234 residing in the recovery database were restored to a subfolder called RecoveredItems in the mailbox called ex2010.
Second, the Recovery-Mailbox switch only accepts the Display Name of your source mailbox. Using the Exchange Alias will not work. If you try to use anything other than Display Name you will receive an error similar to the following:
Mailbox “test1234” doesn’t exist on database “RecoveryDatabase”
Believe me, this will frustrate you because you will see the mailbox definitely exists if you use the Get-MailboxStatistics command. Microsoft does not document the fact that the Restore-Mailbox switch only accepts Display Name very well so hopefully this will save you some time.
Finally, the –TargetFolder, -StartDate, and -EndDate switches are all optional, so you do not need them in all cases.
After my data was restored to my test mailbox, I used the following command to export my data to a PST file:
New-MailboxExportRequest –Mailbox ex2010 –FilePath \Server1PSTDataEmail.pst
Remember that in order for the export to complete successfully you must export the PST data to a share.