Learn How to Back Up Your MS Exchange Server

While much of the world had moved on from Microsoft Exchange in favor of Microsoft 365, many organizations still run it on-premises or as part of a hosted Exchange service.  Whichever way you are using Exchange,  you must back up this data. (You should also back up your Microsoft 365 data as well, but that’s a different article.)  Email is at the core of most organizations, and losing it would likely cost your organization more money that it can afford.  The question is exactly how will you protect this data?

Why back up hosted Exchange?

Look no further than the 2022 story of Rackspace’s hosted Exchange service. They were attacked by ransomware and forced to shutdown operations.  They did move customers immediately over to Microsoft 365, but they did so without their data!  They did eventually recover customer’s data and allow them to download it, but it took months to do so. Customers who had external backups, however, could have easily restored that data into their Microsoft 365 account.  So like I said… back up your Exchange data no matter where it resides.  You will be glad you did so if you ever get hit with ransomware, a major outage that takes out your entire location, or simply make a major administrator mistake that manages to ruin all copies of your Exchange data.

Preferred architecture

Microsoft’s “preferred architecture”  uses built-in redundancy and resilience and considers old-school backups obsolete.  It uses multiple replicated copies of Exchange, each slightly behind the other, to provide an immediate way of restoring a damaged instance – without using backups.

There is merit to parts of their argument. With continuous replication humming away in the background between multiple highly available database copies on different servers, Exchange can certainly shield against quite a few failure scenarios and data loss events without requiring backups to recover.

However, as we grizzled backup vets know, redundancy isn’t the same as backups. What if logically corrupted data gets written to one copy and spreads like malware to all the other copies before you can address it? What if you lose your entire site?

Getting rid of backups might save a few dollars on disks...until something really bad happens. Only restoring from air-gapped backups can get operations back up quicker in such a case.

This is why I am not a fan of the “preferred architecture” of Exchange 2019, and do not think it alone probably can match the air-tight assurance of mature backup solutions. I do think you should deploy Microsoft Native Protection (i.e. lagged replicated copies), because it will be the fastest way to restore Exchange in many cases. But I do think you should deploy only native protection, as it doesn’t cover everything.

Backing up Exchange

image1

Any backups of Exchange must be done with a tool that supports Windows Volume Shadow Servies (i.e. VSS). This is a snapshot system built into Windows that ensures that any tool backing up VSS-supported applications (e.g. Exchange, SQL Server, Sharepoint) is given a stable image to back up.  This is because the files that it is backing up are changing as they are being backed up.  That’s where VSS comes in, by giving the backup app access to an unchanging file during the time of the backup.

A common way to back up Exchange with native tools is to use Windows Server Backup (WSB), which can back up the entire server – including any Exchange databases.  It will interface with VSS and ensure you get a proper backup. Exchange will create the VSS snapshot, and then check the consistency of that backup, before actually performing the backup. This ensures the backup of the database will be consistent during recovery.

In addition to ensuring consistency by using VSS, it’s also important to trigger a log truncation with each backup, which ensures the logs are backed up and cleared out, making room for more logs.  This is done by performing a custom backup and selecting the volume(s) where the Exchange database lives (as opposed to selecting the entire server).

Another way to back up Exchange is to use PowerShell and the Backup Exchange commandlet.  You can specify which database(s) to back up, and the folder to which you want to back it up.

Backup-ExchangeDatabase -Databases "Mailbox Database" -TargetPath "\\backupserver\exchangebackups\mailbox.bkf"

It’s then very easy to schedule this activity to run as often as you’d like.  You can also use this command to see if the database has been successfully backed up:

Get-MailboxDatabase -Server <ServerName> -Status | fl Name,*FullBackup

Whichever method you choose, you can back up the database to a local folder or one accessible to you as a shared folder from another server, such as a deduplication appliance.  Once Exchange is backed up to that folder, you should then back up those files using whatever you centralized backup software is. This will ensure Exchange backups are also sent off-site with all your other backups.

Restore Testing

You will, of course, test recovery of these Exchange backups you’ve been taking, right? You do this by using Windows Server Backup, then selecting Recover. Select the backup file (which can be local or on another server via a share), select the date from which you want to recover, then Exchange as the application. (If Exchange does not show up as a choice, it means you did not perform the proper kind of backup.) You then need to decide if you want to restore to the original location or another one. For testing purposes, it’s probably best to choose an alternate server to restore to. You can use the Event Viewer to see if the recovery worked.

Another thing to consider doing is to actually start the Exchange process and see if the system will receive and/or send mail. This, however, can be quite problematic, as you’d have two servers that think they are your Exchange server. So if you want to do any kind of Exchange testing, make sure to do so in a sandbox, so it cannot actually start sending or receiving email.

Also remember that after any testing is complete, it is really important to shut down the test environment. This is partially due to the risk of having such a server operational and also do to the cost of keeping it running. This is especially true if you are recovering in the cloud, as you are likely paying by the minute.