How to backup Microsoft Exchange?

MS Exchange Server is critical to businesses globally to enable accessible email communication, calendaring, contacts, scheduling, and collaboration. Its high availability (HA) features can ensure continued service in various outage scenarios caused, for example, by a failed server or a data center outage. To ensure HA, the Exchange Server relies on database availability groups (DAGs) to house multiple database copies across users and provide redundancy in case of failure. (at the database or server levels)

However, Exchange Server can fall victim to logical and physical errors, hard disk failure, database corruption, malware infections, and other disaster scenarios. Such events can hinder crucial processes and lead to prolonged downtime. To ensure business continuity, organizations must rely on sensible EDB backups to restore corrupted or lost databases quickly and efficiently. This is why regular, continuous backups of Exchange Server databases are integral to a robust backup strategy.

This article will explore the essence of Exchange Server backups, the different approaches to safeguard Exchange data, and the best practices used to ensure a streamlined database backup and recovery.

To understand the nature of Exchange backups, we first need to grasp the architecture of Microsoft Exchange. The MS Exchange Server is a server application focused on collaboration, designed to run on the Windows Server operating system. MS Exchange supports calendaring, email, contacts, tasks, mobile and web-based data access, and data storage.

MS Exchange Server comprises four primary elements critical for understanding Exchange backups. Those are:

• The system state

The system state includes the local security accounts manager database, the cluster server configuration, the Internet Information Services (IIS) database, and the registry. The cluster server configuration is critical to the mailbox server role during database availability group deployment.

• Active Directory (AD)

Most Exchange servers are stored in Active Directory. This lets users restore lost Exchange server settings via the Setup.exe/Mode:RecoverServer switch in an unattended mode of Exchange Setup. (executed from the command line)

The command relies on data stored in Active Directory during the Exchange installation on a new server with the same name.

• The file system

The file system houses specific configuration files responsible for particular Exchange server settings. Such settings can, for example, define which mailboxes can be transferred simultaneously during migration or present memory usage warning thresholds.

• The Exchange server database

The Exchange database comprises mailbox and public folder databases. The databases keep the most important information in the Exchange Server environment, consisting of two essential parts – the databases themselves and the transaction log files.

The first three abovementioned Exchange components can be backed up via traditional backup tools. However, the Exchange databases require a dedicated Exchange-aware backup solution that can run a Volume Shadow Copy Service (VSS) backup of the target databases.

During a server failure event, users can manually set server roles, connections, and settings but can't recover data – attachments, emails, contacts – without a proper Exchange database backup.

Below, we will explore the four ways to backup Exchange Server databases.

You can back up exchange data in four primary ways (supported natively). Let's explore them below.

• Full backup of the Exchange database and transaction logs

After a full Exchange backup, the Exchange Server clears all old logs for the target database. The process is also referred to as log truncation.

Log truncation is required because the MS Exchange Server uses a write-ahead approach to write new data to the target database. When creating new Exchange data (items), such as emails and calendar events, the data is written to a log file. After a while, the logs are committed to the particular database, and the Exchange Server marks them as "recyclable" to truncate them. This makes the logs shorter and thus saves space whenever a full Exchange backup file is created.

• Incremental backup of transaction logs only

Incremental backups comprise changes made to the logs since the last full or incremental backup. After the process is complete, it clears the logs for the given period.

• Differential backup of transaction logs only

Differential backups of transaction log files record changes made to the logs since the last full backup (only). The approach doesn't truncate the transaction logs and includes only transaction logs up to the current checkpoint. Such backups don't change or delete the log files nor change the database headers.

• Copy backup of databases and transaction logs

Copy backups create exact copies of Exchange data in a separate location. They don't require the Exchange Server to truncate logs after a backup completion event. Such backups are helpful to run tests or diagnostics but are rarely used outside of their primary use case.

As differential backups are rarely used due to their complexity and backup chain elongating, full and incremental backups are the go-to methods for general Exchange backup creation.

Typically, Exchange admins leverage full and incremental backups to backup Exchange databases on an adequate backup schedule. If you periodically perform a full backup of the target database, you can run incremental backups (for transaction logs) between the full backups. This way, you can ensure that all critical data is backed up and available for recovery in a data-loss event.

However, full and incremental backups differ, and it's worth exploring their pros and cons to tailor your unique backup strategy to your needs and preferences.

Pros

• Captures all database data, including tables, indexes, views, and triggers.
• Doesn't rely on another backup to enable recovery; it also provides the most straightforward restoration process.
• Enables point-in-time recovery if you have the corresponding transaction logs.

Cons

• Takes a long time, a lot of bandwidth, and extensive storage space, especially if you frequently modify or add data to your database.
• May affect the database and app performance as it can lock resources or slow down particular operations.

Pros

• Faster to create.
• Smaller than full backup files.
• Reduces the impact of the process on database and app performance as it doesn't lock resources or the entire database.

Cons

• Requires more complex recovery (you must track the backup sequence and backup dependencies).
• Takes more time to restore Exchange databases (you must apply all corresponding incremental backups in the correct order on top of the most current full backup)

Point-in-time recovery allows admins to restore a set of backup data from a specific time in the past via a system or a dedicated tool. The PITR approach relies on logging the database so administrators can enforce restoration of the database as it was at the preferred time.

• Point-in-Time (PIT) Snapshot

As mentioned, PITR relies on logged data for the target database. This set of data is called a Point-in-Time (PIT) snapshot. The PIT snapshot copies databases, data, or files at a specific time and is used to restore data from a particular time or the last created PIT snapshot.

As PIT snapshots are typically read-only, admins can update them by mapping recent snapshots with earlier data copies or copying changed data since the last PIT snapshot.

• Importance of PITR

PITR is helpful following a human error (accidental deletion of records or tables) or database file corruption. In a data-loss or corruption event, it's quickest to use the transaction logs for the database and recover it from the known, good point in time. PITR can be initiated differently for individual databases:

• PITR for PostgreSQL via Timelines
• PITR for MySQL via Binary Log
• PITR for MongoDB via Oplog

PITR is useful as an additional data protection layer and enables quick disaster recovery. Successful PITR requires the backup operation to have a log enabled to record and comprise all relevant database transactions.

The two essential components for PITR are having a reliable base backup and all relevant transactions logged in the log file. The log files enable PITR to restore good transactions and eliminate bad ones (e.g., accidental table deletion). This ensures restoration with minimal data loss.

Note: While convenient, PITR will render the database unavailable during the recovery. Moreover, if the required base backups are located off-site, the process will take longer to restore all relevant data files alongside the transaction logs.

Manual backups offer great flexibility over the backup and restore process but are cumbersome and resource-consuming. Unless you have a few small databases to back up, automating database backups is better to save time, effort, and resources.

In addition to saving time and resources, automated backups can enhance data security and compliance, reduce the risk of human error (accidental deletion, forgetting to create a critical backup), improve performance and data availability, and promote an environment where backup admins can learn new skills and implement best backup practices optimally.

You can automate Exchange database backups via Windows Server Backup or use a dedicated, third-party solution to ensure comprehensive, customizable backups. The sections below will explore how to do so via Acronis Cyber Backup and WSB. You can implement whichever approach you find more suitable for your organization, preferences, and budget.

For a single Exchange server hosting all Exchange services and Exchange data, considering the typical amount and frequency of data changes and server data size, admins can implement daily/nightly full backups complemented by hourly transaction log backups.

To set up and automate Exchange database backups via Acronis Cyber Backup, you must cover the following prerequisites:

• You have a license enabling the installation of an Agent for Exchange.
• You have a machine running one of the supported Microsoft Exchange Server versions.
• You have downloaded the setup file for Acronis Cyber Backup Advanced.
• The Microsoft Exchange writer for VSS is turned on.

Assuming your system meets all the requirements, you can install the Agent for Exchange and the management console on the machine hosting the Exchange Server via the following steps:

1. Log onto the machine as a domain admin and start the setup file.
2. Click "Install Acronis Cyber Backup" and accept the license agreement terms.
3. Select the check box labeled "Back up this machine's data"; on the next page, check the "Microsoft Exchange Server" box.
4. When prompted for a license, select "I purchased a license or a subscription". Proceed to type in your unique license key or import it from a file. After ensuring the proper license is selected, click "Next".
5. Leave the default setting labeled "I will register the component(s) later".
6. Choose if you want the machine to participate in the Acronis Customer Experience Program (CEP) and proceed with the installation.

Assuming installation is complete, you can proceed to schedule backup operations for your Exchange Server. Below, we will explore the steps to schedule one daily full backup combined with hourly incremental backups.

1. Ensure that circular logging is disabled for all databases (or storage groups) of the Exchange Server. If the feature is enabled, the transaction log backup will fail.
2. Click "Create backup plan" in the management console.
3. Click "Items to back up" under the "What to back up" section. Select "Microsoft Exchange Information Store" in the "Data to back up" section. From the data tree, expand the machine and choose the "Microsoft Exchange Information Store" check box located under the machine's name. Click "OK".
4. Click "Location" under the "Where to back up" section and specify the backup storage location.
5. Under the "How to back up" section, select the following: Select "Custom" in the "Backup scheme" section. Click "Add schedule" in the "Full Backup" section. Select "Daily" and set up the schedule to "Every: 1 day(s), Once at: 09:00:00 PM". Click "Add schedule" in the "Transaction log" section. Select "Daily" and set up the schedule as follows: "Every: 1 Days(s), Every: 1 Hour(s)".
6. Select "Custom" in the "Backup scheme" section.
7. Click "Add schedule" in the "Full Backup" section. Select "Daily" and set up the schedule to "Every: 1 day(s), Once at: 09:00:00 PM".
8. Click "Add schedule" in the "Transaction log" section. Select "Daily" and set up the schedule as follows: "Every: 1 Days(s), Every: 1 Hour(s)".
9. Click "OK" to save the custom backup plan.

In "Details", you will see the "Backup plan and tasks" view from the newly created backup plan. Here, you can check the plan's status, monitor the execution state, run or stop the backup plan, and more. Once the configuration is complete, the Agent for Exchange will continuously create backups according to your preferred schedule.

Acronis Cyber Protect

The best backup & recovery software for M365 environments built for business and managed service providers

Learn More

Verifying the Integrity of Your Backup

Backup integrity validation is essential to ensure that backups aren't corrupted before you recover data from them. The preset in Acronis Cyber Backup is: Disabled, meaning you must Enable it to validate backups.

Validation leverages a checksum for every data block comprised in the backup. An exception here is the validation of file-level backups located in cloud storage. Such backups are validated by checking the meta information consistency saved in the backup.

While validation is critical to ensure the integrity of your backups, it's important to note that it is a time-consuming process. (even for small-sized incremental or differential backups). This is due to the validation process checking not only the physically contained data in the backup but also all available, recoverable data by selecting the backup, which requires access to previously created backups. With this information in mind, you can sensibly initiate validation processes to prevent network performance from being affected while ensuring your backups are not corrupted and available for recovery.

Now, we can go over backing up multiple Exchange servers integrated into a cluster by leveraging three advanced features - express full backup, Continuous Data Protection (CDP), and data deduplication.

Now, let's explore the prerequisites and required steps to schedule nightly full backups with the option to restore a lost or corrupted Exchange database to its pre-failure state.

MS Exchange Server includes a plug-in for Windows Server Backup that enables you to create VSS-based backup of Exchange data. So, a possible Windows Server Backup application is to back up (and restore) Exchange databases. You can also back up Exchange via Exchange Management Shell and the Exchange Admin Center.

Let's explore the three native ways to back up Exchange Server data below.

1. Start Windows Server Backup and select "Local Backup".
2. Click "Backup Once..." in the Actions Pane to start the Backup Once Wizard.
3. Select "Different options" from the Backup Options page -> click "Next".
4. Choose "Custom" from the "Select Backup Configuration" page and click "Next".
5. Click "Add Items" on the Select Items for Backup page to choose the volume(s) to add to the backup -> click "OK". It's important to know that you must select volumes instead of individual folders. Choosing individual folders doesn't allow an application-level backup or recovery. (only choosing an entire volume will enable the process)
6. Select "Advanced Settings" and click "Add Exclusion" on the Exclusions tab to add files or file types to exclude from the backup. Here, you can't exclude volumes containing OS components or applications as they are included in the backup by default.
7. Select "VSS full Backup" from the VSS Settings tab -> click "OK" -> click "Next".
8. Select the storage location for the backup from the Specify Destination Type page and click "Next". If you select "Local drives", the Select Backup Destination page will appear. You can choose a backup option from the Backup destination dropdown -> click "Next". You can also choose the "Remote shared folder" option. In this case, the Specify remote folder page will appear. Here, you can specify a UNC path for the backup and configure access control settings. If you want your backup to be accessible only via a specific account, select the "Do not inherit" option. Then, provide a username and passcode for an account with write permissions on the machine hosting the remote folder, and click "OK". If you want the backup accessible by everyone granted access to the remote folder, select "Inherit". Click "Next".
9. If you select "Local drives", the Select Backup Destination page will appear. You can choose a backup option from the Backup destination dropdown -> click "Next".
10. You can also choose the "Remote shared folder" option. In this case, the Specify remote folder page will appear. Here, you can specify a UNC path for the backup and configure access control settings. If you want your backup to be accessible only via a specific account, select the "Do not inherit" option. Then, provide a username and passcode for an account with write permissions on the machine hosting the remote folder, and click "OK". If you want the backup accessible by everyone granted access to the remote folder, select "Inherit". Click "Next".
11. Review the backup settings on the Confirmation page -> click "Backup".
12. You can monitor the status and progress of the backup process on the Backup Progress page.
13. You can click "Close" to exit the Backup Progress page; the backup job will run in the background until completion.

Once the backup is complete, the last backup status will be displayed on the server where you've run the Windows Server Backup. The status should state "Successful". You can also verify a successful backup via the WSB logs.

You can create a recovery database via Exchange Management Shell. This type of mailbox database backup enables mounting and extracting data from the restored database during a recovery process.

After successfully creating a recovery database, you can transfer a restored (or recovered) mailbox database into the backup database. You can then use the NewMailboxRestoreRequest cmdlet to extract data from the recovered database. Following extraction, the data can be merged with an existing mailbox or exported to a folder.backup data

Recovery databases enable you to restore Exchange data from backups or database copies without hindering user access to current data. Assuming you have the required permissions, you can create a recovery database via Exchange Management Shell via the following commands:

Manual Exchange Online mailbox backups typically require users to export mailbox data to a Personal Storage Table (PST) file. The PST file can be stored locally or remotely to ensure data protection. To create it, follow the steps below:

1. Log into Office 365 via your admin credentials. Ensure you have the necessary permissions to export mailboxes.
2. Go to the Exchange Admin Center from the Microsoft 365 admin portal.
3. Navigate to "recipients" in the Exchange admin center and select "mailboxes". Click on the mailbox you wish to back up.
4. From the mailbox properties window, open the mailbox features tab. There, click "Mailbox Export Request". Click the "New" button to create a new export request.
5. Enter the required information in the "New Mailbox Export Request" dialog box:Name for the export requestMailbox which you want to exportFile to Export to, specifying the storage location for the PST file. (e.g., local backup, network share)Content to include, selecting whether to export specific folders or the entire mailboxFilter to export specific data (if needed) based on message types or data ranges (or other applicable filters)Start to choose when to initiate the export; either immediately or at a later, pre-scheduled timeAfter correctly filling in the required information, click "Finish" (or "New", depending on the Exchange Online version) to submit the export request.
6. Name for the export request
7. Mailbox which you want to export
8. File to Export to, specifying the storage location for the PST file. (e.g., local backup, network share)
9. Content to include, selecting whether to export specific folders or the entire mailbox
10. Filter to export specific data (if needed) based on message types or data ranges (or other applicable filters)
11. Start to choose when to initiate the export; either immediately or at a later, pre-scheduled time
12. You can track the export request's progress via the Mailbox Export Requests section in the Exchange admin center, where all request statuses are displayed.
13. After the export request is complete, download the PST file to your preferred storage.

A sensible backup strategy is key to successfully restoring Exchange data. It also complements your Recovery Time Objective (RTO), Recovery Point Objective (RPO), and Service Level Agreements (SLAs). These factors are the most impactful when outlining your backup settings and a long-term backup plan.

Backup frequency largely depends on the rate of change for Exchange resources and the importance of newly created data. For example, a critical, heavily used database resource might require hourly backups, while a less important, rarely used database resource might be okay with a daily backup.

However, it's important to note that even the most essential databases don't require more than two full backups a day. As storage space can be expensive (local or the cloud), it's best to safeguard critical Exchange databases via one or two full backups a day, complemented by incremental (transaction log backups) every hour (or half hour if you're creating extensive data amounts). Such an approach will ensure minimal (or no) data loss even if a disaster event occurs. As long as your backups are securely stored in multiple locations to satisfy the 3-2-1 Rule of Backup, you will always have at least one readily available, up-to-date backup copy to recover essential data and resume business processes with minimal downtime.

Another crucial consideration is your business growth. While weekly full backups paired with a couple of daily incremental can satisfy the backup requirements for a recently launched SMB, they won't be merely enough to protect the data created by a rapidly expanding business. As your company grows and evolves, it will generate more and more data. Hence, it's your responsibility to modify your backup strategy to tailor it to your specific data volumes as time passes. Such a continuous, sensible improvement of your backup approach ensures enhanced data protection, unhindered day-to-day processes, and business continuity.

Backing up Exchange Server is a continuous, evolving process that requires admins to implement best backup practices to ensure data protection, recovery availability, and business continuity.

Let's explore some of those below.

EDB backup is a critical process for many organizations reliant on MS Exchange Server. The process differs from traditional file and folder backups and requires a customized backup schedule to ensure reliable disaster recovery.

Microsoft offers three primary EDB backup options - the Windows Server Backup feature, Exchange Shell Management commands, and the Exchange Admin Center. However, the native data protection included in those may not be enough to safeguard your backup data from advanced threats.

To ensure database integrity, highly customizable backup settings, and cross-location storage (on-premises and the cloud), it's best to rely on a dedicated backup solution, such as Acronis Cyber Backup for Exchange Server.

The software is easy to install, configure, and pilot and offers extensive backup customization (if you decide to leverage it). You can capture your entire Exchange Server or back up specific databases via top-tier backup technology. Once created, backups are easy to browse to find particular mailboxes, emails, and database data to restore exactly what you need without compromising network performance and bandwidth.

In addition to backing up on-premises physical and virtual systems and applications, Acronis Cyber Backup can safeguard Amazon EC2 instances and Microsoft Azure VMs to protect your organization's IT infrastructure completely. Moreover, the software can protect VMware ESXi hosts and Microsoft Hyper-V and recover backups to dissimilar hardware to fortify your virtual infrastructure.

As for RTO optimization, the solution includes Acronis Instant Restore, which can run any physical or virtual Windows (or Linux) system backup as a VMware or Hyper-V to reduce recovery times to mere seconds.

In addition to sensible backup, Acronis offers on-premises and cloud data protection across your entire environment, controlled via a centralized web console to monitor and manage all backup and recovery processes. The console can oversee backups for Microsoft Windows PCs, Mac computers, iPhones, iPads, and Android and Linux devices to grant complete control over your data, systems, and backups. Wherever they reside.