Best Practices for Backing up Exchange Server

Save to My DOJO

Best Practices for Backing up Exchange Server

Email may be the world’s single most mission-critical application. It is something that nearly every company uses and depends on heavily for day to day operations. Given the business-critical nature of email, it can cause various problems if a user accidentally deleted an e-mail message containing important company information.

Thankfully, unless the user performs a hard delete, the message is not actually gone. Instead, it is placed into the user’s Deleted Items folder, and the user can get it back at any time within the folder’s retention period.

But what if a user DOES permanently delete an important message or doesn’t realize that a message was deleted until after it has already been purged from the Deleted Items folder? That’s the topic of this article. In this article, we’ll dive into best practices and considerations for backing up an on-premises Exchange server.

NOTE: This article does NOT cover data protection strategies for Exchange Online hosted in O365/M365, if you’re looking for protection options for that use case you can do so here.

Is a Backup Really Necessary for Exchange Server?

The subject of whether or not Exchange Server backups are really required has been debated for years. Even as far back as 2012, IT pros were discussing a backup abandonment philosophy that was sometimes referred to as zero backup. The basic philosophy behind this concept was that if an organization has enough redundancy in place, there should be no need for traditional backups.

Even today, Microsoft seems to be embracing this philosophy for Exchange Server. According to Microsoft, the “preferred architecture for Exchange Server leverages a concept known as Exchange Native Data Protection. Exchange Native Data Protection relies on native Exchange features to protect your mailbox data, without the use of traditional backups”.

Although this approach can theoretically ensure that Exchange mailboxes remain online at all times, it does little if anything to provide point in time recovery capabilities. Hence, simply going against the grain and actually backing up Exchange could be regarded as an important best practice. Organizations must consider what would happen if there were a need to revert a mailbox database to an earlier point in time due to a malware infection, database corruption, or some other catastrophic event. The idea of forgoing traditional backups is short-sighted and needlessly puts an organization’s mailbox data at risk. As such, organizations should look for a backup solution that can protect mailbox data in a way that meets the organization’s operational needs while also addressing any compliance requirements.

The Need for Single Item Recovery with an Exchange Server

The most important capability to look for in an Exchange Server backup solution is the ability to recover individual mailboxes and individual items within mailboxes.  To those who may be new to Exchange Server, this capability might seem like a basic capability that should exist in any Exchange Server data protection solution. However, single item recovery has always been somewhat elusive in Exchange Server environments.

Exchange Server first gained mainstream popularity back at the time of Exchange 5.x. At that time, Active Directory had not even been invented yet. So Exchange had its own built-in directory database that worked in conjunction with the public and private information store databases. Being that Exchange Server was still rather primitive then, there really wasn’t a good way to perform single item recovery. A few vendors at the time offered what was then called brick-level recovery capabilities. Still, subjectively speaking, it seemed that these recovery techniques failed almost as often as they worked.

Back then, the only guaranteed way to recover a mailbox item was for an organization to keep two spare physical servers on hand. Both of these servers were connected to an isolated network segment. If the organization needed to recover the contents of a user’s network, the administrator would restore a domain controller backup to one of the servers. An Exchange Server backup from the same period of time was then restored to the other server. This was a full restoration, so the server hardware had to be nearly identical to the organization’s production Exchange box.

Once both restorations were complete, the administrator would log into the newly restored domain controller on the isolated network. From there, they would change the password of the user whose data needed to be recovered, thereby giving the administrator the ability to log in as that user. The administrator would then install Windows and Outlook onto a PC that existed on the isolated network segment. Finally, the user could log in as the user, locate the deleted item, and then export it to a PST file. This PST file would then be presented to the user who had requested the recovery so that the user could import the file’s contents into their mailbox. Needless to say, single item recovery for Exchange Server was not a trivial matter. The recovery process was very time consuming and labor-intensive.

Exchange Server and Modern Single Item Recovery

Over time Exchange Server became more advanced, and Microsoft began giving administrators better options for recovering Exchange mailbox data. In fact, Exchange Server now includes native single item recovery capabilities that do not depend on traditional backups. Even so, these capabilities come with some significant caveats.

The biggest issue with using Exchange Server’s single item recovery capabilities is that they are disabled by default ( You can only recover an item if single item recovery was enabled before the item was deleted. Therefore, another best practice would be to enable single item recovery right now if it has not already been enabled.

Single item recovery is enabled on a per-mailbox basis, and you can check to see if single item recovery has been enabled for a mailbox by using the following command:

Get-Mailbox <Name> | Format-List SingleItemRecoveryEnabled,RetainDeletedItemsFor

The command listed above will tell you whether or not single item recovery is enabled and will also give you the retention period for deleted items. This brings up an important point. By default, deleted items are only retained for 14 days ( After that, they are permanently deleted. You can, however, set a custom retention period. If, for example, you wanted to set the retention period to 30 days while also enabling single item recovery for all mailboxes, you could do so by using this command:

Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox')} | Set-Mailbox -SingleItemRecoveryEnabled $true -RetainDeletedItemsFor 30

It is also worth noting that you cannot use the EAC to restore recovered items. Instead, you will have to use a pair of PowerShell commands like these:

Search-Mailbox "<User Name>" -SearchQuery "from:'<Sender’s name>' AND <keyword>" -TargetMailbox "Discovery Search Mailbox" -TargetFolder "<recovery folder name>" -LogLevel Full

Search-Mailbox "Discovery Search Mailbox" -SearchQuery "from: ‘<sender’s name>' AND <keyword>" -TargetMailbox "<recipient’s name>" -TargetFolder "Recovered Messages" -LogLevel Full -DeleteContent

Needless to say, using PowerShell to search for and recover messages can be a very tedious process.

The Exchange Server Recovery Database

Even though Microsoft tends to encourage Exchange Native Data Protection and PowerShell based recovery, Exchange Server does include a recovery database feature that allows a traditional backup application to be used.

A recovery database is a special purpose mailbox database that exists to allow administrators to extract restored mailbox data. A backup can be restored to the recovery database, and then items can be extracted on an as-needed basis.

Windows Server Backup has the ability to restore an Exchange Server database to a recovery database. The problem, however, is that Windows Server Backup only supports file-level recovery, not application-level recovery ( This means that when the restoration process completes, the database will be in a dirty shutdown state, which makes it unusable. Because of this, an administrator would then have to use the time consuming and sometimes problematic ESEUTIL tool to force the database into a clean state. Only then will the administrator be able to mount the database and then use the New-MailboxRestoreRequest cmdlet to restore a mailbox.

The Bottom Line

Native Exchange Server data recovery processes leave a lot to be desired. Using Windows Server Backup to restore data to a recovery database is a tedious, time consuming, and potentially error-prone process. Furthermore, administrators must resort to using PowerShell to perform the actual mailbox recovery, and single item recovery is not directly supported. As previously noted, Exchange Server does support single item recovery, but only if the capability is enabled, and the item that needs to be restored has not exceeded its retention period. Even then, the recovery process involves using a series of messy PowerShell commands.

When it comes to something as important as data recovery, it is better to use a third-party backup solution, such as Altaro. A third-party provider like Altaro provides a much more intuitive way of recovering Exchange Server data (including single item recovery) and does not force administrators to work through the recovery process using a series of complicated and obscure PowerShell commands. That is the last thing you want to be worried about when you’re in the process of attempting to recover important company data.

Altaro Backup Solutions
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

Leave a comment

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