Monday, November 30, 2015

Exchange 2010 - Restore from a "Recovery Database"

The restoration of a deleted item from a backup may be necessary when all other options have been exhausted. But before resorting to this option, we should ask ourselves:

  1. Can we simply recover the deleted item from the Deleted Items folder (the Outlook "Recycle Bin")?
  2. Can we recover the deleted item from the "Recover Deleted Items" folder (the Outlook "Dumpster")? Remember to highlight the folder from which the item was deleted when using this option.
  3. In the case of a disabled or removed mailbox (there is a slight but important difference), can we locate the mailbox in the "Disconnected Mailboxes" section of the Exchange Mailbox Console (EMC) and reconnect the mailbox to the associated Active Directory user account (or another user account)? Note that if we "removed" the mailbox, we will have deleted the associated Active Directory user account as well and would have to restore this object also.
Note: if the terms or concepts above are unfamiliar, please conduct an online search for clarification.


If we must restore a mailbox (or specific items) from backup, we can use a "Recovery Database". Previously, with Exchange 2007, this was known as a "Recovery Storage Group - RSG)" but since storage groups were eliminated from Exchange 2010 (and more recent versions), the name has changed. In this scenario, I will use Exchange 2010 (SP3 - RU10) but the procedure is very similar for Exchange 2013 (please see references at the end of this article - there is a link to the procedure for Exchange 2013).

The obvious pre-requisite is the availability of a recent backup. I created such a backup with the native Windows 2008 (R2) backup software which is now able to backup Exchange (this was not initially the case when Windows 2008 was released). The reader will have to make adjustments if using a 3rd party backup system such as Commvault or Veeam (etc.).


***

The recovery procedure can be divided into three major steps:
  1. Restore the Exchange database and logfiles to a specific location.
  2. Create (and then mount) the recovery database using these files.
  3. Perform the restore operations.
For step 3, it is essentially a matter of "copying" items from the recovery database (RDB) to the database where these items were originally located with the New-MailboxRestoreRequest cmdlet.



Restore the Exchange database and logfiles

I have created a folder named "A_RestoredFiles" on my C: drive. This is the location to which I will restore the Exchange database and transaction log files before creating (and then mounting) the RDB. Here is the restore procedure...

We open "Windows Server Backup" on the Exchange server. In the Action pane, select "Recover":





In our scenario (please see my previous blog post), we created the backup on a second hard drive. On the "Getting Started" page, we would therefore select "This server (EX13-1)":




We then select the backup we want to restore by date (and time):




Since Exchange is an application, we select the "Applications" option:




The server may have several applications but in our scenario there is only one. So we simply select Exchange:


Note: I opt not to check the roll-forward recovery option. This choice works for me (if you read what follows) but may or may not be suitable in other circumstances.



At this point, we can choose to recover to the original location or to another location. Since I want to create a separate Recovery Database using the restored files, I will select the second option and then designate the location where I want to restore the application:





We can simply click "Recover" on the confirmation screen:




And wait for the restore to complete:




The operation restores the database and log files based on their original location (file path):




Now that we have restored the database and transaction log files, we can use them to create the Recovery Database.




Create (and mount) the Recovery Database (RDB)

 When we restore the Exchange database and transaction log files to a new location, the database is usually in what is called a "Dirty Shutdown" state. We can verify this with the ESEUTIL command line tool (and we can also remedy this situation with the same tool).

First, we go to the location where the .edb file was restored and run the eseutil /mh command as shown here:

[PS] C:\>sl .\A_RestoredFiles
[PS] C:\A_RestoredFiles>sl .\C_
[PS] C:\A_RestoredFiles\C_>sl .\A-DB1
[PS] C:\A_RestoredFiles\C_\A-DB1>eseutil /mh db1.edb

Note: the Exchange database exists in a file with the .edb extension.

Note: "sl" is the abbreviation of the Powershell cmdlet "Set-Location". Similar to the traditional "cd" command, it allows us to move around the file structure at the command line.


This is probably the result that you would obtain in comparable circumstances:

[...]
State: Dirty Shutdown
Log Required: 386-388 (0x182-0x184)
Log Committed: 0-389 (0x0-0x185)
[...]

Note: the output of the eseutil /mh command is quite abundant so I have cut all but the most relevant parts above.

But why is this important?

Because a database will not mount when it is in a "Dirty Shutdown"state.

We can change the shutdown state with the eseutil /r command but eseutil needs to know the location of the transaction log files. We can either designate the location of these files or copy them to the location of the database file (eseutil looks for the log files in this location by default). I will opt for the second option...

Copy...




Paste...




Note the respective path of the database file and the log files.



We now repair the database with the ESEUTIL /R command:

[PS] C:\A_RestoredFiles\C_\A-DB1>eseutil /r E01 /i /d

[...]

Initiating RECOVERY mode...
    Logfile base name: E01
    Log files: <current directory>
    System files: <current directory>
   Database Directory: <current directory>

Performing soft recovery...
                      Restore Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ...................................................

Operation completed successfully in 4.212 seconds.



Now we can see that the database is in a clean shutdown state and can be mounted:

[PS] C:\A_RestoredFiles\C_\A-DB1>eseutil /mh db1.edb

[...]

State: Clean Shutdown
Log Required: 0-0 (0x0-0x0)
Log Committed: 0-0 (0x0-0x0)
Log Recovering: 0 (0x0)

[...]


At this point, we need to clarify the status of the DB1.edb file we restored and repaired with ESEUTIL (so it would be in a "Clean Shutdown" state). This file is the restored database but Exchange is not aware of the existence of this file and does not recognize it as a "mailbox database". We can observe this for ourselves with the Get-MailboxDatabase cmdlet:

[PS] C:\>Get-MailboxDatabase

Name                    Server          Recovery        ReplicationType
----                           ------          --------        ---------------
DB1                      EX13-1          False           Remote

Exchange only sees the original copy of the database and not the restored file that we want to use as the Recovery Database.

Therefore, we need to create a new "Mailbox Database" with the restored file and specify that it is a "Recovery" database. We can accomplish that with the following command:

[PS] C:\>New-MailboxDatabase -Recovery -Server EX13-1 -Name RDB1 -EdbFilePath "C:\A_RestoredFiles\C_\A-DB1\DB1.edb" -LogFolderPath "C:\A_RestoredFiles\C_\A-DB1"

Note: the "-Recovery" parameter makes this mailbox database a recovery database (RDB).


We may see the following warning stating that the database must be brought into a clean shutdown state before it can be mounted. In our case, we have already accomplished this task and can disregard the warning:

WARNING: Recovery database 'RDB1' was created using existing file C:\A_RestoredFiles\C_\A-DB1\DB1.edb. The database must be brought into a clean shutdown state before it can be mounted.

Now "RDB1" is recognized as a (recovery) mailbox database.

[PS] C:\>Get-MailboxDatabase

Name                   Server          Recovery    ReplicationType
----                         ------            --------        ---------------
DB1                      EX13-1          False           Remote
RDB1                   EX13-1          True            None


This is what we see in the Exchange Management Console (EMC):



All we have to do next is mount the database:

[PS] C:\>Mount-Database RDB1


If we want to see what mailboxes are in the database, we can use the Get-MailboxStatistics cmdlet. The Get-Mailbox cmdlet does not seem to produce output with a RDB:

[PS] C:\>Get-Mailbox -Database RDB1
[PS] C:\>Get-MailboxStatistics -Database RDB1 | fl DisplayName

DisplayName : Aisha Bhari
DisplayName : Alex Heyne



Restore mailbox items from the RDB to the source database

Since Exchange 2010 SP1, the New-MailboxRestoreRequest cmdlet enables us to restore items from the RDB to the source database . This cmdlet replaces the former Restore-Mailbox cmdlet (now deprecated).

I intend to illustrate some of the possible restore options by presenting the status quo of the user mailbox of Alex Heyne (test user) when the backup mentioned above was taken and just before I deleted the items shown below (not only from the original folder locations but also from the recycle bin and the "dumpster").

Then I will show what his mailbox looks like once the items are restored.

So, when the backup was taken, there were 3 messages in Alex Heyne's Inbox and 3 messages in his Sent Items folder:






Once again, all these messages were deleted after the backup was taken: from the Inbox and Sent Items folder but also the Recycle Bin and "Dumpster".

Of course, it is only later that we realize these messages should have been retained!

How can we retrieve them?

The New-MailboxRestoreRequest with the following parameters restores the messages the their original location:

New-MailboxRestoreRequest -SourceDatabase RDB1 -SourceStoreMailbox "Alex Heyne" -TargetMailbox "Alex Heyne"

I will not post additional screenshots here because you would simply see what you see above: essentially a return to the "status quo ante" or "situation as it was before".

Note: since all the messages were deleted there were no conflicts. But what if the backup included items that were not deleted? What would happen then? Default behavior is to keep the source item or in other words overwrite the item still present in the target database. There are parameters that change this default behavior. Please consult the references at the end of this post and in particular (for this subject) the article by Paul Cunningham.


This combination of parameters restores the entire mailbox to a single folder named "Restored Files" (in my example):

New-MailboxRestoreRequest -SourceDatabase RDB1 -SourceStoreMailbox "Alex Heyne" -TargetMailbox "Alex Heyne" -TargetRootFolder "Restored Items"

And this is what the user would see in Outlook:


The entire folder structure, including the normally hidden "Recoverable Items" folder, is restored to the designated "TargetRootFolder" as well as the content of the folders (Sent Items are shown above).

Note: I have performed the restore operation with Outlook open and in that case, the items usually appear instantly with no user interaction. In the example above, however, it was necessary to close and reopen Outlook. Try this before concluding that the restore operation failed.


This combination of parameters restores only the Inbox to a single folder name "Restored Files":

New-MailboxRestoreRequest -SourceDatabase RDB1 -SourceStoreMailbox "Alex Heyne" -TargetMailbox "Alex Heyne" -TargetRootFolder "Restored Items" -IncludeFolders "#Inbox#"


Note: the "Recoverable Items" folder is still restored. We can avoid this by adding the following parameter:

-ExcludeDumpster


One more example: the following combination allows us to restore Alex Heyne's entire mailbox to the specified folder inside of Alan Reid's mailbox:

New-MailboxRestoreRequest -SourceDatabase RDB1 -SourceStoreMailbox "Alex Heyne" -TargetMailbox "Alan Reid" -TargetRootFolder "Restored Items" -AllowLegacyDNMismatch



This could be useful if the user is no longer with the organization and someone has been designated to recover some important items (pertaining to a contract, for example) from a backup of the former employee's mailbox.

The "AllowLegacyDNMismatch" parameter is mandatory if we want to restore the mailbox into another user's mailbox like in the example above. By default, Exchange will not allow this. We have to specify explicitly that this is our intention. Otherwise, we will see the following error:

Source mailbox's legacyExchangeDN '/O=MYNET/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=ALEX.HEYNE' doesn't match [...].


The restore request may require some time to finish. We can check the status of the request(s) with this cmdlet:

Get-MailboxRestoreRequest


After the restore is complete, we can remove the restore requests with this combination of cmdlets:

Get-MailboxRestoreRequest | Remove-MailboxRestoreRequest


Furthermore, there is no need to keep the Recovery Database permanently, so we would want to dismount it and then remove it with the following cmdlets:

Dismount-Database RDB1

Remove-MailboxDatabase RDB1

After we execute the cmdlet above, we should see a warning like this: 

WARNING: The specified database has been removed. You must remove the database file located in... C:\RestoredFiles\C_\A-DB1\DB1.edb from your computer manually if it exists. Specified database: RDB1

It is simply a matter of deleting the files in question from either File Explorer or the command line.





References:

Technet reference:



Article by Exchange MVP Mike Pfeiffer:



Article by Exchange MVP Paul Cunningham:


4 comments:

  1. No doubt, this article is informative. On the other hand, I would like to point out that how an Exchange Administrator can recover the data if the backup is not updated, then creating recovery storage groups are of no use. In that case, professional exchange database recovery software like http://bit.ly/1odgPAC comes to the rescue.

    ReplyDelete
  2. Really it hard to work on Outlook after once PST file gets corruption. I too once encountered PST file corruption but thanks to solution i get here following which i able to resolve the issue:- http://www.download-scanpstexe.com/

    ReplyDelete
  3. Recovery entire data of Exchange priv1.edb and pub1.edb with a click. Use Exchange Server Recovery program effortlessly transfer entire EDB data to Outlook PST file. The application works excellently for repairing EDB files and convert Exchange data to PST file. MS Exchange EDB extract tool is safe and convenient to use for conversion of Exchange mailbox into PST file.

    See full details at: Exchange Server Recovery


    ReplyDelete
  4. The Exchange Mailbox Recovery an easy to use software designed to recover mailboxes from corrupted or damaged exchange server ( 2016 / 2013 / 2010 / 2007 / 2003 / 2000 and 5.5 ) database. This software does a complete scan of the corrupted Microsoft exchange server database and extracts all the mailboxes. After recovery, all folders from these mailboxes will be restored to a safe location. The log report will give entire information about the recovery process. See more at: https://softcart.wordpress.com/exchange-mailbox-recovery/

    ReplyDelete