Applies to: Exchange Server SE / 2019 / 2016 / 2013 / 2010
Exchange Server supports Recovery Databases (RDBs) for restoring mailbox data from a recovered database without interrupting access to the active mailbox database. This applies to Exchange Server Subscription Edition, Exchange Server 2019, and Exchange Server 2016.
One useful scenario is restoring the contents of an old mailbox into a different existing mailbox. The recovered database is mounted as an RDB, the source mailbox is identified by its mailbox GUID, and New-MailboxRestoreRequest copies the data into the target mailbox.
In This Article
- 1. What Is a Recovery Database?
- 2. Prepare the Restored Database
- 3. Create the Recovery Database
- 4. Mount and Check the Recovery Database
- 5. Restore the Mailbox to a Different Mailbox
- 6. Monitor the Restore and Clean Up
- 7. Key Takeaways
1. What Is a Recovery Database?
A Recovery Database is a special mailbox database used only for recovery. It lets you mount a restored Exchange database and extract mailbox data from it while users continue working with the production databases.
The target mailbox must already exist. The restore request copies or merges data from the mailbox stored in the RDB into that connected mailbox.
2. Prepare the Restored Database
Restore the required .edb file and its transaction logs from backup to a recovery folder. The exact restore process depends on the backup product.
The database must be in Clean Shutdown state before it can be mounted as an RDB. You can first check its current state with Eseutil:
eseutil /mh "E:\Recovery\RDB01\DB01.edb"If the database reports Dirty Shutdown, use Eseutil /R with the correct log generation prefix to replay the restored transaction logs and bring the database into Clean Shutdown state. For example:
eseutil /r E00 /l "E:\Recovery\RDB01" /d "E:\Recovery\RDB01"E00 is only an example. Use the actual log generation prefix for the restored database. After replaying the logs, run eseutil /mh again and confirm that the database is in Clean Shutdown state.
If the backup came from Exchange Server Subscription Edition or Exchange Server 2019 with MetaCacheDatabase (MCDB) enabled, Microsoft documents using the /i switch during recovery to remove stale MCDB linkage from the restored database:
eseutil /r E00 /d "E:\Recovery\RDB01" /i3. Create the Recovery Database
Create an RDB that points to the restored database and log path:
New-MailboxDatabase -Recovery -Name "RDB01" -Server "EX01" -EdbFilePath "E:\Recovery\RDB01\DB01.edb" -LogFolderPath "E:\Recovery\RDB01"Confirm that Exchange created it as a recovery database:
Get-MailboxDatabase "RDB01" | Format-List Name,Server,Recovery,EdbFilePath,LogFolderPathMicrosoft’s documented recovery sequence includes restarting the Microsoft Exchange Information Store service after creating the RDB:
Restart-Service MSExchangeISImportant: Restarting the Information Store service affects mounted mailbox databases on that server, so plan this step for an appropriate maintenance window.
4. Mount and Check the Recovery Database
Mount-Database "RDB01"
Get-MailboxStatistics -Database "RDB01" | Format-Table DisplayName,MailboxGuidFind the mailbox you want to recover and note its MailboxGuid. Using the GUID is safer than relying only on the display name.
5. Restore the Mailbox to a Different Mailbox
The following example restores the entire source mailbox from the RDB into another existing mailbox and places the recovered content under a separate top-level folder:
New-MailboxRestoreRequest -Name "Recover-User01" `
-SourceDatabase "RDB01" `
-SourceStoreMailbox "SOURCE-MAILBOX-GUID" `
-TargetMailbox "recoveryuser@contoso.com" `
-TargetRootFolder "Recovered-User01" `
-AllowLegacyDNMismatch-AllowLegacyDNMismatch allows the restore to continue when the source physical mailbox and target mailbox do not have matching LegacyExchangeDN values. By default, Exchange checks the source LegacyExchangeDN against the target mailbox’s LegacyExchangeDN or matching X500 proxy address to reduce the risk of restoring data into the wrong mailbox. Verify the target mailbox carefully before using this switch.
If you are restoring data back into the original mailbox and the LegacyExchangeDN check already matches, the switch is not required. You can also omit -TargetRootFolder if you want Exchange to merge the recovered folders directly into the target mailbox folder structure.
6. Monitor the Restore and Clean Up
Exchange identifies a restore request as TargetMailboxAlias\RequestName. In this example, the identity is recoveryuser\Recover-User01. Monitor the restore request with:
Get-MailboxRestoreRequestStatistics -Identity "recoveryuser\Recover-User01" | Format-List Name,Status,PercentComplete,*Bytes*After the status is Completed, verify the recovered data in the target mailbox before removing anything.
Remove-MailboxRestoreRequest -Identity "recoveryuser\Recover-User01"
Dismount-Database "RDB01"
Remove-MailboxDatabase "RDB01"Remove-MailboxDatabase removes the database object from Active Directory. It does not delete the physical database and log files. Delete those files manually only after you have confirmed that the recovery operation is complete and the restored data is no longer needed.
7. Key Takeaways
- Recovery Databases are supported in Exchange Server SE, 2019, and 2016.
- The restored database should be in Clean Shutdown state before you mount it as an RDB.
- Use the source mailbox GUID when creating the mailbox restore request.
- When restoring into a different mailbox, verify the target carefully before using -AllowLegacyDNMismatch.
- Keep the RDB and restored files until the recovered mailbox data has been validated.
References
- Microsoft Learn – Restore data using a recovery database
- Microsoft Learn – New-MailboxRestoreRequest
- Microsoft Learn – Restore a database backup when MCDB is enabled
Cloud and infrastructure professional with nearly two decades of experience in enterprise IT environments, spanning public cloud, private cloud, and hybrid architectures.