In Exchange 2013 we can recover our database backups in three ways:
- Restore a Database Backup to its original location: This recovery process is usually performed when the database has serious problems (corruption, virus infections, etc.). In this scenario the administrators need to restore the data from all the mailboxes stored in this database, since no other methods (i.e. Database passive copies using DAG) are available.
- Restore a Database Backup to the Recovery Database: This recovery process is usually performed when the users need to recover single items and the methods described in the section “Performing a Single Item Recovery” has been followed without positive results or when we need to restore a limited number of mailboxes without impacting the rest of the users.
- Restore a Database Backup to a different location: This recovery process is usually performed when the administrator need to recover the EDB and LOG files separately in order to perform some extra troubleshooting.
Supported backup Technologies:
Exchange 2013 supports only Exchange-aware, Volume Shadow Copy Service (VSS)-based backups.
Exchange 2013 includes a plug-in for Windows Server Backup that enables you to make VSS-based backups of Exchange data. You can also use Windows Server Backup to back up and restore your Exchange databases. To back up and restore Exchange 2013, you must use an Exchange-aware application that supports the VSS writer for Exchange 2013, such as Windows Server Backup (with the VSS plug-in), Microsoft System Center 2012 – Data Protection Manager, or a third-party Exchange-aware VSS-based application.
Exchange 2013 introduces a significant change from the VSS writer architecture used in Exchange 2010 and Exchange 2007. These earlier versions of Exchange included two VSS writers: one inside the Microsoft Exchange Information Store service (store.exe) and one inside the Microsoft Exchange Replication service (msexchangerepl.exe). In Exchange 2013, the VSS writer functionality previously found in the Microsoft Exchange Information Store service has been moved to the Microsoft Exchange Replication service. The new writer, which is named Microsoft Exchange Writer, is now used by Exchange-aware VSS-based applications to back up active and passive database copies, and to restore backed up database copies. Although the new writer runs in the Microsoft Exchange Replication service, it requires the Microsoft Exchange Information Store service to be running for the writer to be advertised. As a result, both services are required to back up or restore Exchange databases.
Recovery Database
A recovery database (RDB) is a special kind of mailbox database that allows you to mount a restored mailbox database and extract data from the restored database as part of a recovery operation. You can use the New-MailboxRestoreRequest cmdlet to extract data from an RDB. After extraction, the data can be exported to a folder or merged into an existing mailbox. RDBs enable you to recover data from a backup or copy of a database without disturbing user access to current data.
Microsoft Exchange Server 2013 supports the ability to restore data directly to a recovery database. Mounting the recovered data as a recovery database allows the administrator to restore individual mailboxes or individual items in a mailbox. Restoring to a recovery database can be accomplished in two ways:
- If a recovery database already exists, the application can dismount the database, restore the data onto the recovery database and log files, and then remount the database.
- The database and log files can be restored to any disk location. Exchange analyses the restored data and replays the transaction logs to bring the databases up to date, and then a recovery database can be configured to point to already recovered database files.
Difference between a mailbox database and a recovery database
RDBs are different from standard mailbox databases in several respects:
- An RDB is created by using the Exchange Management Shell.
- Mail can’t be sent to or from an RDB. All client protocol access to an RDB (including SMTP, POP3, and IMAP4) is blocked. This design prevents using an RDB to insert mail into or remove mail from the messaging system.
- Client MAPI access using Microsoft Office Outlook or Outlook Web App is blocked. MAPI access is supported for an RDB, but only by recovery tools and applications. Both the mailbox GUID and the database GUID must be specified when using MAPI to log into a mailbox in an RDB.
- Mailboxes in an RDB can’t be connected to user accounts. To allow a user to access the data in a mailbox in an RDB, the mailbox must be merged into an existing mailbox, or exported to a folder.
- System and mailbox management policies aren’t applied. This design prevents items in an RDB from being deleted by the system during the recovery process.
- Online maintenance isn’t performed for RDBs.
- Circular logging can’t be enabled for RDBs.
- Only one RDB can be mounted at any time on a Mailbox server. The use of an RDB doesn’t count against the database limit per Mailbox server.
- You can’t create mailbox database copies of an RDB.
- An RDB can be used as a target for restore operations, but not backup operations.
- A recovered database mounted as an RDB isn’t tied to the original mailbox in any way
Using a recovery database
Before you can use an RDB, there are certain requirements that must be met. An RDB can be used for Exchange 2013 mailbox databases only. Mailbox databases from previous versions of Exchange aren’t supported. In addition, the target mailbox used for data merges and extraction must be in the same Active Directory forest as the database mounted in the RDB.
An RDB can be used to recover data in several situations, such as:
- Same server dial tone recovery: You can perform a recovery from an RDB after the original database has been restored from backup, as part of a dial tone recovery operation.
- Alternate server dial tone recovery: You can use an alternate server to host the dial tone database, and then later recover data from an RDB after the original database has been restored from backup.
- Mailbox recovery: You can recover an individual mailbox from backup when the deleted mailbox retention period has elapsed. You then extract data from the restored mailbox and copy it to a target folder or merge it with another mailbox.
- Specific item recovery: You can restore from backup data that has been deleted or purged from a mailbox.
An RDB is designed for mailbox database recovery under the following conditions and scenarios:
- The logical information about the original database and the mailboxes in that database remains intact and unchanged in Active Directory.
- You need to recover a single mailbox or a single database. Recovery scenarios include:
- Recovering or repairing a database while a dial tone database is in use, with the goal of merging the two databases.
- Recovering a database on a server other than the original server for that database. If needed, you can then merge the recovered data back to the original server.
- Recovering deleted items that users previously deleted from their mailbox, after the deleted item retention period has expired.
An RDB cannot be used when you have to recover public folder content. In addition, RDBs are generally not designed for scenarios in which you have to restore entire servers, when you have to restore multiple databases, or when you’re in an emergency situation that requires changing or rebuilding your Active Directory topology.
Create a recovery database
You can use a recovery database, which is a special kind of mailbox database, to mount a restored mailbox database and extract data from the restored database as part of a recovery operation. After you create a recovery database, you can move a recovered or restored mailbox database into the recovery database, and then use the New-MailboxRestoreRequest cmdlet to extract data from the recovered database. After extraction, the data can then be exported to a folder or merged into an existing mailbox. Using recovery databases, you can recover data from a backup or copy of a database without disrupting user access to current data
Using the exchange shell
This example creates the recovery database RDB on the Mailbox server TESTEXMBX1.
New-MailboxDatabase -Recovery -Name RDB -Server TESTEXMBX1
This example creates the recovery database RDB on the Mailbox server TESTEXMBX1 using a custom path for the database file and log folder.
New-MailboxDatabase -Recovery -Name RDB -Server TESTEXMBX1 -EdbFilePath “C:\EXCH-DBs\Recovery\RDB.EDB” -LogFolderPath “C:\EXCH-DBs\Recovery”
Recovering a database to a recovery database
In this scenario a situation is simulated where a database is required to be restored and there could be multiple reasons while for a database to be restored including the scenario of losing all healthy copies of the database, single item recovery or the Single Mailbox recovery. It is recommended to have this tested with the same backup software as production.
For this scenario to be simulated we did the following steps.
- We took the Backup of database from windows Backup.
- We restored the backup to an alternate location.
- We inspected the database and then played the required log files to bring the Data base in clean state.
- We created the recovery Database.
We mounted the recovery database.
Taking the backup using the windows backup
The Windows Backup feature is enabled and we did the backup by pressing “Backup Once”
When the Exchange Backup were taken through windows backup, It has to be full volume which needs to be backed up and backup should be taken from the serve where the active copy needs to be mounted.
Following screen shots depicts the Backup process.
Recover the backup to an alternate location
Inspecting the restored data and backup state
Performing the soft Recovery and make the Database in clean State by using but check point file was deleted.
Open exchange management shell and run the below after navigating to the restored database path
Eseutil /r e00 /d /i
Creating the recovery database
New-MailboxDatabase -Recovery -Name RDB -Server TESTEXMBX1 -EdbFilePath “C:\EXCH-DBs\Recovery\RDB.EDB” -LogFolderPath “C:\EXCH-DBs\Recovery”
Inspecting the recovery database
Get-MailboxStatistics -Database rdb | fl displayname
Performing a Single Mailbox Recovery
Use the Shell to recover data using a recovery database
To create a restore request, you must provide the DisplayName, LegacyDN, or MailboxGUID for the soft-deleted or disabled mailbox.
New-MailboxRestoreRequest -SourceDatabase RDB -SourceStoreMailbox “test2” -TargetMailbox alternate.mailbox -TargetRootFolder RestoredForTest2User -AllowLegacyDNMismatch
after a while you can check the move request status using the below:
Get-MailboxRestoreRequest | Get-MailboxRestoreRequestStatistics
You can then go to the alternate.mailbox export the restored files to pst and supply them to the user, or else you may directly restore to the user mailbox. Always make sure that the quota limit is not exceeded.
Best Regards;
Hisham Mezher
Hisham Mezher 