Exchange Server 2013 Backup and Restore 101 (Part 7)

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


At the beginning of this article series, we defined the goal to show the administrators how to protect and restore information from Exchange Server 2013 using built-in tools. There are several tools in the market to protect Exchange data, and the vast majority uses an agent installed on the Exchange Server, and each tool has its own documented process to backup and restore exchange data.

Although many organizations are moving away from the traditional backup using Exchange native tools, there are still a lot of organizations requiring traditional backups, and there is the scenario where an Exchange Server resides on a remote/distant office and a regular backup is the only way to protect that data.

There are also customers running Office365 and they are getting used to the idea that there is no traditional backup/restore process available other than the recovery deleted items process (as seen in the beginning of this series) and the Single Item Recovery in conjunction with the high availability of the Mailbox Databases to keep the exchange data.

In this article, we are going to show how to protect using a built-in tool which is Windows Server Backup, and after that, we will be restoring the databases in several different ways which we’ll see in the next article of this series.

Using Windows Server backup…

Before starting with Windows Server Backup to protect an Exchange Server database, the administrator must be aware of a few key points to make sure that Windows Server Backup will work properly with your Exchange Server environment, as follows:

  • Only full backups for Exchange Server are supported, no incremental or differential backups
  • Protection is done at the volume level, we are not going to see the database items during the creation of the protection job
  • The tool will run only locally, there is no remote administration
  • We can restore Exchange Database afterwards, but that won’t save us from protecting and restoring the entire volume first
  • Exchange logs will be purged after a successful backup
  • The destination of the backup can be local or a remote network share
  • There is no integration between Windows Server Backup and Recovery Database feature of Exchange Server 2013 (this process is manual, and we will cover it in this series)
  • The restore process is brutal, it will restore the entire content of the volume, which means that a lot of space is required to perform a restore process, so plan well how you are going to keep the information.

Now that we are on the same page with the limitations we can go ahead and install Windows Server Backup We can add a new feature using Server Manager, and being at the Features page we need to select Windows Server Backup from the list (Figure 01) and use default values to complete the installation. After the installation, the tool is ready to use and there is no requirement for a restart.

Figure 01

If you prefer the PowerShell to install your windows features, then just run the cmdlet Add-WindowsFeature Windows-Server-Backup as shown in Figure 02.

Figure 02

In this article, we will have a single Exchange Server with a few Mailbox Databases created after the installation and all of them are on the C: drive. We are going to organize the existent environment to support better integration with Windows Server Backup, by moving all existent databases to a volume that will be used only for Exchange data, and getting rid of any additional mailbox database.

The first step is to make sure that we have a volume for our Mailbox Databases. We can use the cmdlet below (Figure 03) to list all the mailbox databases of any given server and the Mailbox Database file path and its log files.

Get-MailboxDatabase –Server <ServerName> | fl Name,EdbFilePath,LogFolderPath

As we can see, we have three Mailbox Databases on this server and all of them are on the C: drive and that is not the ideal scenario when using Windows Backup. To be honest this setup is not good in any production environment for several reasons: first, we do not want the same disk being shared between Operating System and Exchange Databases; second, if the disk is running out of space then it will bring down the server and consequently the mail system. Finally, using a single volume will affect Windows Server Backup where we do not have a place to store the backup, and the only option would be a network share.

Figure 03

Preparing the Exchange Server 2013 environment…

For this article, we added 2 additional disks (M: drive for the Exchange Databases and X: drive allocated for the backup files and restores), we know based on the previous figure (Figure 04) that we have three databases and they are still on the C: drive.

In order to move our production mailbox databases (DB01 and DB02) to the new drive we can use the cmdlet below, and we need to repeat the process for each mailbox database.

Move-DatabasePath <DatabaseName> -EDBFilePath M:\EXDatabases\DB01\DB01.edb –LogFolderPath M:\EXDatabases\DB01

The directory structure defined in the cmdlet will be created automatically, after entering the cmdlet above we need to confirm the move for the database and log files.

Figure 04

At this point both production databases (DB01 and DB02) are in the new location, however we still have the default mailbox database on the same server (by default they start with Mailbox Database and a long number). Since we are adjusting the Exchange Server to support the Windows Backup, we should remove all Mailbox Databases from the C: drive.

The first step is to list all the Mailbox Databases for that default mailbox database and using the following cmdlet, we can accomplish such task.

Get-Mailbox –Database “Mailbox Database <number>”

After that we can use the same cmdlet and add | New-MoveRequest –TargetDatabase <DBName> to move all existent mailboxes to the new location. The entire process is shown in Figure 05.

We should wait for the completion of all move requests, and we can use the Get-MoveRequest to track the status of the process.

Figure 05

Since we are planning to remove the first Mailbox Database, it is most likely that Mailbox Database has arbitration mailboxes, and we can find that out using the following cmdlet.

Get-Mailbox –Database “Mailbox Database <number>” –Arbitration

If there is arbitration mailboxes on that mailbox database, then we need to list all arbitration mailboxes followed by the | New-MoveRequest –TargetDatabase <DBName>, as shown in Figure 06.

Figure 06

After having all mailboxes and arbitration mailboxes moved, we should make sure that we remove all the requests using Remove-MoveRequest cmdlet. The next step is to remove the last mailbox database that still resides on the C: drive and we can use the following cmdlet (Figure 07):

Remove-MailboxDatabase “<DBName>”

Figure 07

After all changes, we can check the result in Figure 08 where we have only two Mailbox Databases on the server and now we are ready to start protecting them using Windows Server Backup.

Figure 08

The Mailbox Databases were never protected, and we can validate that by checking the Mailbox Database properties using EAC (Figure 09). We will see that there is no information about the last full or incremental backup, and we will be checking this information again after running the backup using Windows Server Backup.

Figure 09

Protecting Exchange Databases…

In the Figure 10, we show the main page of the Windows Server Backup, and in order to protect Mailbox Databases we are going to set it up for a daily backup, the first step is to click on Backup Schedule…

Figure 10

In the Getting Started page. A welcome page for the backup schedule wizard will show up, just click on Next.

In the Select Backup Configuration page. We are going to select Custom and then click Next.

In the Select Items for Backup page. We need to click on Add Items and select all volumes that contain Exchange Mailbox Databases (in our case M: volume), as shown in Figure 11. After selecting all volumes that contain Exchange Mailbox Databases and log files, click on Advanced settings, and select VSS Full Backup option under VSS Settings, as shown in Figure 12.

Figure 11

Figure 12

In the Specify Backup Time page. We are going to select once a day and we will be using 11PM as the time to run the protection, please change according to your environment and click Next.

In the Specify Destination Type page (Figure 13). Here we can define where the protection files will be placed. There are several options: we can use a dedicated hard disk (recommended), an existent volume or a shared folder on the network. In our case, we are going to use the option Back up to a volume and click Next.

The first option is recommended because all the disk activity will be in a separate disk, and that disk is going to be used only for the Windows Server Backup. Using this option the disk will be formatted and it will not be visible on Windows Explorer.

Figure 13

In the Select Destination Volume page. Click on Add and select the volume desired, and click Next.

Finally, in the last page a summary of all settings that we defined so far is going to be listed, click on Finish.

The results of this new backup job that we have just scheduled is a new Task in Task Scheduler being listed under Microsoft\Windows\Backup item, as shown in Figure 14.

Figure 14

Now it is time to wait for the scheduled task to run, and after that, we can see the results on the main page of Windows Server Backup, Figure 15 The same initial page will provide details about schedule jobs, last activities, future jobs and status of the volume/disk being used to store the backup files.

Figure 15

After having the first backup complete, we can go back to the mailbox database properties using Exchange Admin Center (EAC), and if everything went fine, we will have information on the Last Full Backup field, as shown in Figure 16. As part of the same process, all the logs that were committed to the mailbox database were purged as part of the backup of the database.

Figure 16


In this tutorial, we went over the basic steps to configure an Exchange Server 2013 to work with the built-in Windows Server Backup. In our next article of this series, we will be able to restore the database information to restore a mailbox server, and after that we will work with dial tone restore, mailbox portability and Recovery Mailbox Database, so we have tons of cool stuff to check in this series.

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

Leave a Comment

Your email address will not be published.

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

Scroll to Top