Exchange Server 2013 Backup and Restore 101 (Part 10)

By /

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article, we went through a scenario where the exchange server went down, and the administrator had to restore the server using /RecoverServer switch and then because of the delay on getting the backup information and the pressure from the business, we decided to use the dial tone recovery process.

So far, we have created a temporary mailbox database (TDB01), configured just one mailbox to that new temporary database and we perform the initial testing on the client side. We also tested the client side using Outlook Client and Outlook Web App (OWA), in both environments we noticed that only the new messages (as expected) are in the mailbox and the user can start working however, without historical data. When using an Outlook that was configured before the crash, a pop-up will be displayed when the user opens Outlook and he can decide to opt for the new content or access to the historical data.

Besides the scenario that we described in the previous article about a slow backup process, there are several reasons why an administrator may want to use a dial tone recovery, such as complete failure on the storage system that contained the exchange information, a failure of a disk where the database resides. In that second case, we may want to create the dial tone database even on the same server.

Preparing the environment…

After restoring the service to the end-users and enabling them to access an empty mailbox, our backup team restored the Mailbox Database and made it available to us on our Exchange Server.

The first step is to create a Recovery Database (RDB) (Figure 01) and this procedure must be done using Exchange Management Shell, the cmdlet is listed below and in our article, we are going to create a Recovery Database called RDB01 on the C:\RDB01 folder for logs and edb file. Note: The folder structure will be created automatically by the cmdlet.

New-MailboxDatabase –Recovery –Name <DBName> -Server <ServerName> -EDBFilePath ‘X:\folder\file.edb’ –LogFolderPath ‘X:\folder\’

Image
Figure 01

Keep in mind that Recovery Databases are never shown on the Exchange Admin Center (Figure 02).

Image
Figure 02

The second step is to copy the database restored to the new location that we defined for the Recovery Database (Figure 03), if there is log files available, make sure that you add them to the same location. The goal here is to bring the database information as close as possible to the time of the crash.

Image
Figure 03

The backup team restored the database with its original name, however we defined the name for the database as RDB01.edb during the Recovery Database creation. To avoid any issues, the database file will be renamed to RDB01.edb for the time being, and we are going to place this original database file in the folder that is being used by the Recovery Database.

We can always check the database to see the current state by running the command eseutil /mh <EDBFile.edb> as shown in Figure 04. If the database shows as Clean Shutdown then the database is ready to be mounted, however, check if there are any logs to be added to the folder location before moving forward with the next step, after all we want to replay as many logs as possible on that recovery database.

Image
Figure 04

Our next step is to mount the original database in our Recovery Database, and in order to do that we are going to use the cmdlet mount-database, and to check the status of the database we will be running Get-MailboxDatabaseCopyStatus. If the recovery database mounts successfully, then it can be dismounted and we can move on to the next step. These following cmdlets below are shown in Figure 05.

Mount-Database RDB01

Get-MailboxDatabaseCopyStatus

Dismount-Database RDB01

Image
Figure 05

Now that we validated that the original database can be mounted, our next step is to create a folder (we are going to call it Swap Area) and we should move the current RDB01.edb (which is the original database restored by the Backup Team) to that folder and just to be safe let’s rename the EDB file as DB01 – Original.edb

Bringing the original mailbox database into production…

The next step is to dismount the current temporary database (TDB01 which contains all data since the crash), and it is recommended to perform such task during non-business hours, because it will impact the end users and they are probably not very happy with IT Team since the crash of the server. The steps to dismount the temporary database and checking afterwards is shown in Figure 06.

Image
Figure 06

At this point we do not have any active mailbox database on the server, so we will move the temporary database to the same folder Swap Area and to be safe we will add – Temp DB on its name for the time being. In that same folder, we are going to have the database before the crash (DB01 – Original.edb) and the database that contains the information after the crash (TDB01 – Temp DB.edb), as shown in Figure 07.

Image
Figure 07

Right now, all users are configured to use the temporary database, and for that reason, we need to copy the original database (DB01 – Original.edb) to the same location where we have the TDB01 database, but before going forward check these key points:

  • If you have created your TDB01 in a disk with low disk space, then it may be better to move the TDB01 to the a location that will hold the original database;
  • I recommend removing all files from the folder where is the TDB01, just to be safe create a folder (in this example Old) and move all the log files to that location
  • Since the database was mounted before in production, you will not need the log files and that is the reason that only the EDB file is being utilized

The final step is to rename the database that we copied to the temporary database path location to the same name that is defined in the Exchange configuration, in our example the file was renamed from DB01 – Original.edb to tDB01.edb, as shown in Figure 08.

Image
Figure 08

Finally, we can mount the database, as shown in Figure 09.

Image
Figure 09

After this point, the clients will have all the data back however, without the new content that is in our Swap Area folder inside of the TDB01 – Temp DB.edb file. In Figure 10, we can see that the Outlook Web Access is listing all the original content of the Number6’s mailbox right before the crash.

Image
Figure 10

If you are using Outlook client, then the following message will appear (Figure 11), click on OK and restart your Outlook and the data from the original database will be available.

Note:
Sometimes Outlook client is stubborn and does not close right away, in that case use the Task Manager to make sure that Outlook is not running before reopening Outlook.

Image
Figure 11

Conclusion

In this article, we went through the process to restore the original database and now the users have their data back, however any messages sent and received in the dial tone are not available at this time. In our next article of this series, we will merge that information with the production database.

If you would like to read the other parts in this article series please go to:

About The Author

Anderson Patricio is a Canadian MVP in Cloud and Datacenter Management, and Office Server and Services, besides of the Microsoft Award he also holds a Solutions Master (MCSM) in Exchange, CISSP and several other certifications. Anderson contributes to the Microsoft Community with articles, tutorials, blog posts, twitter, forums and book reviews. He is a regular contributor here at Techgenix.com, MSExchange.org, ITPROCentral.com and Anderson Patricio.org (Portuguese).

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top