Restoring Mailbox Data from a Recovery Database in Exchange 2010 SP1
In this post I am going to outline this process of restoring mailbox data from a recovery database in Exchange 2010 SP1. This is kind of a long overdue follow up to my previous post on backing up Exchange 2010 using Windows Server Backup (WSB), which you can find right over here. What I am going to do here is restore an old database backup that was created using the steps in that post. Then I'll show you how to mount it as a recovery database, and then we'll take a look at several methods used to restore mailbox data from it using the Exchange Management Shell.
So here's the scenario; I've got a mailbox server called MBX1 with the following disk layout:
The MBX1 server has a single database called DB01 and the database file (along with the logs) are stored on the E:\ drive. I am doing regular backups using WSB and storing them on the F:\ drive. I basically need to do a point in time restore and retrieve some data from about seven months ago.Even though I have more recent backups, they don't have the data I need. I am going to create a Recovery database from a previous backup so I can selectively restore mailbox data from it into the production database.
Restoring the Backup
The first thing I'll do is start WSB on the MBX1 server and select Recover from the Action menu:
As I mentioned earlier, the backups are stored on the F:\ drive on MBX1. On the Getting Started screen I'll select This server (MBX1) to specify the location of the backups and then I'll click Next:
I need to go back to the end of last year to retrieve the data I'm interested in. You can see that on the Select Backup Date screen that the oldest successful backup I have within this time frame is from December 9th of 2010. I'll select that date and click Next:
On the Select Recovery Type screen I'll select Applications and then click Next:
On the Select Application screen I'll select Exchange for the application to recover, then I'll click Next:
On the Specify Recovery Options screen, I want to leave my existing database alone and restore the backup to an alternate location. Then I can create a Recovery Database later using these files and restore only specific mailbox data from the backup. I am going to set the restore location to E:\RecoveryDB since I know the E:\ drive has plenty of space. After that, I'll click Next:
At this point I am ready to restore the data, so on the Confirmation screen I'll hit the Recover button and the restore will begin immediately:
I can monitor the status of the restore on the Recovery Progress screen. As long as the status comes back as Completed I am in good shape:
As you can see from the above screen shot, the restore was successful, so I can click Close. I can navigate out to the E:\ drive to view the files:
Everything looks good so far, I just need to make a note of a couple things before I move on. Notice the directory structure in the above screen shot. The database was restored to a sub folder of the recovery location specified during the restore. It restored the database in a folder called DB01 (which was the original folder name) in a sub directory called E_ since it was originally stored on the E:\ drive. I need to remember the path and the log generation prefix for the database, which is e01, as shown above. These details will be important for getting the database into consistency in the next step.
Getting the Database into a Clean Shutdown State
In order for Exchange to mount a database, it needs to be in a clean shutdown state. I'll use the eseutil tool to play any outstanding transactions into the database to get it clean. Before I begin, I'll open a command prompt, switch to the directory that contains the database and logs, and use the following command to view the status:
When reviewing the output, the database state will be reported as Dirty Shutdown:
What I will do next is perform a soft recovery to get the database consistent. I'll run the following command to do this:
The /r specifies that I'm doing a soft recovery. The e01 is the log generation prefix for the database. I'm using the /d switch without any arguments to specify the database path, which is in the current directory. Since the logs are also located here, I don't need to use the /l switch, as it defaults to the current path. Once the operation has completed successfully, I can run eseutil again with the /mh switch to verify the database is clean shutdown:
Now that my database has been restored and brought to a clean shutdown state I can create the Recovery Database.
Creating the Recovery Database
The next step in the process is to create the Recovery database using the database files restored from the backup. To do this, I'll use the New-MailboxDatabase cmdlet with the following syntax:
Notice that I've specified the path to the database and log files using the location where the database was restored. Also, the key to creating the Recovery database is to make sure you use the -Recovery switch parameter, as shown above. You can see I got a warning message after running the command stating the Recovery database was created using an existing file, and that I need to ensure that the database is in a clean shut down state before I try to mount it. I already did this in the previous step, so I can safely ignore this message and mount the database using the following command:
The Recovery database is now mounted, and I'm ready to restore mailbox data.
Finding Mailboxes and Performing a Simple Mailbox Restore
Now that my Recovery database is online, I need to be able to see what mailboxes are available for restores. I can use the Get-MailboxStatistics cmdlet to do this:
If you're looking for a specific mailbox, you can filter the results using the following syntax:
You can see in this command I've used the ? alias for the Where-Object cmdlet. I'm using the -like operator to filter the results and only show me the mailboxes that start with Xavier.
When restoring mailbox data from a Recovery database in Exchange 2010 SP1, we use the New-MailboxRestoreRequest cmdlet. When running this cmdlet, the source mailbox in the recovery database needs to be identified using one of three possible values; the DisplayName, MailboxGUID, or LegacyExchangeDN values. Keep in mind that you cannot reference the source mailbox using the Exchange Alias when performing a restore.
So, let's take a look at the restore process. Based on the previous commands I can see that there is a copy of my mailbox in the Recovery database. To do a complete restore of the mailbox data to the original mailbox that is currently active in the production database I'll use the following command:
To Force Operation when Domain Mismatch:
Depending on the size of the mailbox, it may take quite some time to perform the restore. I can keep tabs on the progress using the following one-liner:
Dealing with Multiple Mailboxes with the same DisplayName
It's possible that a Recovery database will have multiple mailboxes with the same display name. This can happen if there were one or more disconnected versions of a mailbox, in addition to an active mailbox, in the same database during the time of the back up. In this case, you can use the MailboxGuid value to identify the source mailbox when doing a restore. Consider the following:
Here you can see that there are two mailboxes with the same display name in the Recovery database. One has a DisconnectDate defined, meaning it is a disconnected mailbox, and the other one does not which means it was the active mailbox in the database at the time of the backup. If you run into a scenario where there are multiple mailboxes in a database with the same display name, use the above command to determine the MailboxGuid of each mailbox. You can then use this value to identify the correct mailbox when performing a restore.
Restoring Individual Mailbox Folders
Here you can see that I am using the -IncludeFolders parameter to specify that only data from the Inbox should be restored from the mailbox in the recovery database:
The -IncludeFolders will accept a list of one or more mailbox folders. You can specify well-known folder names as well as personal folders using this parameter. Notice that the value needs to be enclosed in hash marks (#). For example, if you wanted to restore only the contacts folder, use #Contacts#, or #Tasks# for the Tasks folder, and so on. For more details, check out the help for this parameter in the TechNet documentation for the New-MailboxRestoreRequest cmdlet. If you simply want to restore a single root folder, check out the -SourceRootFolder parameter.
Restoring to an Archive Mailbox
Restoring a mailbox to a users archive is as simple as tacking on the -TargetIsArchive switch parameter to our original restore command. Here's the command and output:
Obviously, you'll need to ensure that the target mailbox has been archive enabled for this to work.
Restoring to an Alternate Mailbox
By default, the New-MailboxRestoreRequest cmdlet looks for a matching LegacyExchangeDN on the source and destination mailbox, or checks to see that an X500 proxy address on the target mailbox corresponds to the LegacyExchangeDN on the source mailbox. This ensures that you do not accidentially restore mailbox data to the wrong location. If you need to restore data to an alternate mailbox, you can use the -AllowLegacyDNMismatch switch parameter:
In this example, I am restoring the data from my mailbox in the recovery database to a sub-folder of the administrator mailbox called Restore. Here's a screen shot of the administrator mailbox after running the above restore command:
Be careful when restoring to alternate mailboxes. If you omit the -TargetRootFolder parameter, the data will be restored and merged into the existing folders in the target mailbox. On the other hand, that might be exactly what you want — if so, just remove the -TargetRootFolder parameter.
Bulk Restores
You might find yourself in a situation where you need to restore data from all mailboxes in a recovery database. For example, let's say you need to restore the Contacts folder for all of your mailboxes. In this case, you could use a foreach loop to iterate through each mailbox in the recovery database and restore that particular folder to the active mailboxes:
This might take a while; you can monitor the progress using the Get-MailboxRestoreRequest with the -Status parameter:
As you've seen, there are a lot of steps and multiple options when it comes to restoring data from a recovery database. Obviously, this is not something you want to learn on the fly when a disaster strikes. I'd highly recommend documenting and testing your restore procedure on a regular basis.
In this post I am going to outline this process of restoring mailbox data from a recovery database in Exchange 2010 SP1. This is kind of a long overdue follow up to my previous post on backing up Exchange 2010 using Windows Server Backup (WSB), which you can find right over here. What I am going to do here is restore an old database backup that was created using the steps in that post. Then I'll show you how to mount it as a recovery database, and then we'll take a look at several methods used to restore mailbox data from it using the Exchange Management Shell.
So here's the scenario; I've got a mailbox server called MBX1 with the following disk layout:
- C:\ - System Drive
- E:\ - Exchange Database
- F:\ - Database backups
The MBX1 server has a single database called DB01 and the database file (along with the logs) are stored on the E:\ drive. I am doing regular backups using WSB and storing them on the F:\ drive. I basically need to do a point in time restore and retrieve some data from about seven months ago.Even though I have more recent backups, they don't have the data I need. I am going to create a Recovery database from a previous backup so I can selectively restore mailbox data from it into the production database.
Restoring the Backup
The first thing I'll do is start WSB on the MBX1 server and select Recover from the Action menu:
As I mentioned earlier, the backups are stored on the F:\ drive on MBX1. On the Getting Started screen I'll select This server (MBX1) to specify the location of the backups and then I'll click Next:
I need to go back to the end of last year to retrieve the data I'm interested in. You can see that on the Select Backup Date screen that the oldest successful backup I have within this time frame is from December 9th of 2010. I'll select that date and click Next:
On the Select Recovery Type screen I'll select Applications and then click Next:
On the Select Application screen I'll select Exchange for the application to recover, then I'll click Next:
On the Specify Recovery Options screen, I want to leave my existing database alone and restore the backup to an alternate location. Then I can create a Recovery Database later using these files and restore only specific mailbox data from the backup. I am going to set the restore location to E:\RecoveryDB since I know the E:\ drive has plenty of space. After that, I'll click Next:
At this point I am ready to restore the data, so on the Confirmation screen I'll hit the Recover button and the restore will begin immediately:
I can monitor the status of the restore on the Recovery Progress screen. As long as the status comes back as Completed I am in good shape:
As you can see from the above screen shot, the restore was successful, so I can click Close. I can navigate out to the E:\ drive to view the files:
Everything looks good so far, I just need to make a note of a couple things before I move on. Notice the directory structure in the above screen shot. The database was restored to a sub folder of the recovery location specified during the restore. It restored the database in a folder called DB01 (which was the original folder name) in a sub directory called E_ since it was originally stored on the E:\ drive. I need to remember the path and the log generation prefix for the database, which is e01, as shown above. These details will be important for getting the database into consistency in the next step.
Getting the Database into a Clean Shutdown State
In order for Exchange to mount a database, it needs to be in a clean shutdown state. I'll use the eseutil tool to play any outstanding transactions into the database to get it clean. Before I begin, I'll open a command prompt, switch to the directory that contains the database and logs, and use the following command to view the status:
Code:
eseutil /mh DB01.edbWhen reviewing the output, the database state will be reported as Dirty Shutdown:
What I will do next is perform a soft recovery to get the database consistent. I'll run the following command to do this:
Code:
eseutil /r e01 /dThe /r specifies that I'm doing a soft recovery. The e01 is the log generation prefix for the database. I'm using the /d switch without any arguments to specify the database path, which is in the current directory. Since the logs are also located here, I don't need to use the /l switch, as it defaults to the current path. Once the operation has completed successfully, I can run eseutil again with the /mh switch to verify the database is clean shutdown:
Now that my database has been restored and brought to a clean shutdown state I can create the Recovery Database.
Creating the Recovery Database
The next step in the process is to create the Recovery database using the database files restored from the backup. To do this, I'll use the New-MailboxDatabase cmdlet with the following syntax:
Code:
New-MailboxDatabase -Name RecoveryDB -EdbFilePath E:\RecoveryDB\E_\DB01\DB01.edb -LogFolderPath E:\RecoveryDB\E_\DB01 -Recovery -Server mbx1Notice that I've specified the path to the database and log files using the location where the database was restored. Also, the key to creating the Recovery database is to make sure you use the -Recovery switch parameter, as shown above. You can see I got a warning message after running the command stating the Recovery database was created using an existing file, and that I need to ensure that the database is in a clean shut down state before I try to mount it. I already did this in the previous step, so I can safely ignore this message and mount the database using the following command:
Code:
Mount-Database RecoveryDBThe Recovery database is now mounted, and I'm ready to restore mailbox data.
Finding Mailboxes and Performing a Simple Mailbox Restore
Now that my Recovery database is online, I need to be able to see what mailboxes are available for restores. I can use the Get-MailboxStatistics cmdlet to do this:
Code:
Get-MailboxStatistics -Database RecoveryDBIf you're looking for a specific mailbox, you can filter the results using the following syntax:
Code:
Get-MailboxStatistics -Database RecoveryDB | ?{$_.DisplayName -like 'Xavier*'}You can see in this command I've used the ? alias for the Where-Object cmdlet. I'm using the -like operator to filter the results and only show me the mailboxes that start with Xavier.
When restoring mailbox data from a Recovery database in Exchange 2010 SP1, we use the New-MailboxRestoreRequest cmdlet. When running this cmdlet, the source mailbox in the recovery database needs to be identified using one of three possible values; the DisplayName, MailboxGUID, or LegacyExchangeDN values. Keep in mind that you cannot reference the source mailbox using the Exchange Alias when performing a restore.
So, let's take a look at the restore process. Based on the previous commands I can see that there is a copy of my mailbox in the Recovery database. To do a complete restore of the mailbox data to the original mailbox that is currently active in the production database I'll use the following command:
Code:
New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox 'Xavier_Mustin' -TargetMailbox Xavier_MustinDepending on the size of the mailbox, it may take quite some time to perform the restore. I can keep tabs on the progress using the following one-liner:
Code:
Get-MailboxRestoreRequest | Get-MailboxRestoreRequestStatisticsDealing with Multiple Mailboxes with the same DisplayName
It's possible that a Recovery database will have multiple mailboxes with the same display name. This can happen if there were one or more disconnected versions of a mailbox, in addition to an active mailbox, in the same database during the time of the back up. In this case, you can use the MailboxGuid value to identify the source mailbox when doing a restore. Consider the following:
Code:
Get-MailboxStatistics -Database RecoveryDB | ?{$_.DisplayName -like 'Isabel*'} | fl DisplayName,MailboxGuid,DisconnectDateHere you can see that there are two mailboxes with the same display name in the Recovery database. One has a DisconnectDate defined, meaning it is a disconnected mailbox, and the other one does not which means it was the active mailbox in the database at the time of the backup. If you run into a scenario where there are multiple mailboxes in a database with the same display name, use the above command to determine the MailboxGuid of each mailbox. You can then use this value to identify the correct mailbox when performing a restore.
Code:
New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox 4a1d2118-b8cc-456c-9fd9-cd9af1f549d0 -TargetMailbox ihillRestoring Individual Mailbox Folders
Here you can see that I am using the -IncludeFolders parameter to specify that only data from the Inbox should be restored from the mailbox in the recovery database:
Code:
New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox administrator -TargetMailbox administrator -IncludeFolders '#Inbox#'The -IncludeFolders will accept a list of one or more mailbox folders. You can specify well-known folder names as well as personal folders using this parameter. Notice that the value needs to be enclosed in hash marks (#). For example, if you wanted to restore only the contacts folder, use #Contacts#, or #Tasks# for the Tasks folder, and so on. For more details, check out the help for this parameter in the TechNet documentation for the New-MailboxRestoreRequest cmdlet. If you simply want to restore a single root folder, check out the -SourceRootFolder parameter.
Restoring to an Archive Mailbox
Restoring a mailbox to a users archive is as simple as tacking on the -TargetIsArchive switch parameter to our original restore command. Here's the command and output:
Code:
New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox 'Xavier_Mustin' -TargetMailbox Xavier_Mustin -TargetIsArchiveObviously, you'll need to ensure that the target mailbox has been archive enabled for this to work.
Restoring to an Alternate Mailbox
By default, the New-MailboxRestoreRequest cmdlet looks for a matching LegacyExchangeDN on the source and destination mailbox, or checks to see that an X500 proxy address on the target mailbox corresponds to the LegacyExchangeDN on the source mailbox. This ensures that you do not accidentially restore mailbox data to the wrong location. If you need to restore data to an alternate mailbox, you can use the -AllowLegacyDNMismatch switch parameter:
Code:
New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox 'Xavier_Mustin' -TargetMailbox administrator -TargetRootFolder Restore -AllowLegacyDNMismatchIn this example, I am restoring the data from my mailbox in the recovery database to a sub-folder of the administrator mailbox called Restore. Here's a screen shot of the administrator mailbox after running the above restore command:
Be careful when restoring to alternate mailboxes. If you omit the -TargetRootFolder parameter, the data will be restored and merged into the existing folders in the target mailbox. On the other hand, that might be exactly what you want — if so, just remove the -TargetRootFolder parameter.
Bulk Restores
You might find yourself in a situation where you need to restore data from all mailboxes in a recovery database. For example, let's say you need to restore the Contacts folder for all of your mailboxes. In this case, you could use a foreach loop to iterate through each mailbox in the recovery database and restore that particular folder to the active mailboxes:
Code:
foreach($mailbox in Get-MailboxStatistics -Database RecoveryDB) {New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox $mailbox.DisplayName -TargetMailbox $mailbox.DisplayName -SourceRootFolder Contacts}
Code:
Get-MailboxRestoreRequest -Status QueuedAs you've seen, there are a lot of steps and multiple options when it comes to restoring data from a recovery database. Obviously, this is not something you want to learn on the fly when a disaster strikes. I'd highly recommend documenting and testing your restore procedure on a regular basis.