Backup and DR
Microsoft Exchange Backup Guide
Although many organizations have already moved their infrastructure to the cloud, on-premise Microsoft Exchange servers are still widely used by businesses. For that reason, Exchange server backup and restore remains critical for many organizations.
This article explains how to back up Exchange servers. We provide an overview of the Exchange backup process, then offer tips and best practices for Microsoft Exchange backup and recovery.
Microsoft Exchange Architecture
MS Exchange Server is a collaborative server application designed by Microsoft to run on the Windows Server operating system. It supports email, contacts and tasks, calendaring, web-based and mobile information access, and data storage.
There are four critical components that are important in terms of Exchange backup:
- Active Directory (AD). Since most Exchange server settings are stored in Active Directory, you can recover lost Exchange server settings by using the Setup.exe /Mode:RecoverServer switch in unattended mode (from the command line) of Exchange Setup. This command uses the information stored in AD during the installation of Exchange on a new server with the same name.
- The system state. This includes the registry, local security accounts manager database, the IIS database, and the cluster server configuration (which is a critical part of the mailbox server role when DAGs are deployed).
- The file system. There are particular settings stored in configuration files on the file system itself (memory usage warning thresholds or the number of mailboxes that can be moved at the same time during a migration).
- The Exchange server database. This includes both mailbox and public folders databases. These databases contain the most important information in an Exchange Server environment, which consists of two parts: the database files themselves and transaction logs.
Unlike all other Exchange components, which can be backed up with standard backup tools, the databases require a proper Exchange-aware backup software that can run VSS backup of the databases.
In case of server failure, you can set the server roles, connections and settings manually, but there is no way to recover the data (emails, attachments, contacts) without understanding how to backup Exchange database.
For the purposes of this guide, we will discuss how to back up and recover Exchange mailbox servers.
Microsoft Exchange Backup: Databases and Transaction Logs
There are four types of Exchange backup that are supported natively:
- Full Backup of the database and the transaction log file. After full Exchange backup ends, the MS Exchange server clears old logs for the given database. This process is also called log truncation.
- Copy Backup of the database and the transaction log file. MS Exchange does not truncate logs after copy backup. This type of Exchange backup is useful for tests or diagnostics.
- Incremental backup of the transaction log only. This backs up changes in the logs since the last full or incremental backup and then clears the logs for that period.
- Differential backup of the transaction logs is performed to record changes since the last full backup. Differential backup does not truncate the transaction logs. It includes only the transaction log files up to the current checkpoint. Differential backups do not delete or change the log files or change the database headers.
Generally, administrators use full and incremental backup types for Microsoft Exchange backup. They periodically perform full backups of the entire base and run incremental backups of logs between these full backups. Differential backups are performed rarely since this backup method makes the Exchange backup chain longer and more complicated. Copy backup is often used for tests.
For more information on the different types of backup operations, check out our guide:
Further reading Types of Backup
MS Exchange Transaction Logs
The transaction log keeps records about all operations in the database. If you have the latest transaction log backup, you can recover the exact state of that database.
For safety and capacity purposes, it is recommended to house the transaction files on a completely different and very reliable (mirrored) physical volume that is distinct from the database files associated with these logs.
Log Truncation
One of the problems that commonly impact Exchange servers is log growth. As each transaction is recorded, logs increase in size. You can easily run out of the log disk space, so you need to truncate logs from time to time. Here are two ways to delete logs or truncate to save space on a transaction log disk for future operations:
1. To perform a full Exchange-aware backup.
- If you use backup software that is not designed for Exchange backup of mailbox databases, your logs won’t be cleared and you will run out of drive space. All of your databases with log files on a full disk will then dismount, causing the server to stop working.
- If you run a full Exchange-aware backup, the backup software will require the Exchange system to truncate the logs.
2. To truncate the logs manually.
This log truncation method is usually performed during emergencies when there is no way to create a full regular Exchange backup instead.
Here are several cases when you might need manual log truncation:
- You are out of transaction log disk space and you haven’t performed a full backup recently, so the next full backup will take several days to complete.
- Backup software failed to perform a backup job, and your logs remain untouched.
- You are running an Exchange test environment and would like to get rid of unnecessary logs.
Please note that manual log truncation won’t work if the database that logs are associated with is mounted. In addition, after deleting logs manually, you will not be able to perform recovery to a specific point in time.
Further reading How to Truncate Logs on Exchange Server without Running a Backup
Circular Logging
Circular logging is an alternative to performing a full backup job for log truncation. It is a method of conserving hard disk space in the Exchange transactional logging process. It works by overwriting individual log files to keep the transaction log (the set of all log files) from expanding without limit on the hard disk.
This feature is often used in cases where the backup software does not support Exchange backup.
Circular logging is not recommended because, in case of failure of the host disk, you only will be able to restore data to the point of the last backup. All subsequent changes will be lost.
The process of enabling the circular logging feature varies between different Exchange server versions. For more information on this feature, please refer to our blog post on circular logging.
Further reading Exchange Circular Logging
MS Exchange Mailbox Server Recovery
To recover an Exchange mailbox server you need to:
- Deploy the new Exchange server with the same server role (mailbox server).
- Give the server a different name.
- Restore the database data from your backup repository.
- Mount recovered databases to the new server
- Switch the old users to the new server.
- Restore the server settings. In most cases, you have to do this manually. If the failed server is still in Active Directory, you can read the settings from it and set the same configurations for a new one.
MS Exchange Transaction Log During Recovery
When you mount an Exchange database, the Exchange server does the following:
- Reads transaction logs.
- Determines the name of the last log file that was applied to the database before failure.
- Examines the names of log files that are assigned to the database in the mounted server.
- If there is a difference, the Exchange system “replays” the log files in the directory by applying every single transaction that has occurred since the failure.
When all available logs are replayed, your database will be back to the exact state it was when the latest log file was written.
Please note that this restore process is valid only for databases mounted in Recovery Storage Groups (RSG) for Exchange 2003/2007, or as a Recovery Database (RDB) for Exchange 2010/2013/2016, or if the active database is flagged as allowing overwrite.
Exchange Server Item-Level Restore
As noted above, native database level backup and restore in Exchange lacks granularity, and it does not provide the ability to recover individual mailboxes, emails or calendars.
Several commercial Exchange backup software tools, including MSP360 Backup, feature granular, item-level restore that helps to restore particular Exchange items. This functionality is closely related to the brick-level backup method.
MSP360 Backup features item-level restore for MS Exchange 2010 edition.
Further reading Item-Level Restore for Exchange 2010 with MSP360 Backup
The point in Time Recovery
With the point in time recovery feature, you can restore your Exchange database to the state it was at a specific point of time. To do that, you need to restore the database from the last full backup before this point in time, and then restore all log files between then and the desired time point.
After you have all the logs and database in a good location, you need to:
- Create an RSG (Recovery Storage Group) or Recovery Database that points to that location.
- Look in the folder you saved the logs to. Each of the logs will have a timestamp on them that should carry over from the backup.
- This timestamp will allow you to pinpoint the log file that was written right before the mailbox was deleted.
- Once you find that, you can delete every log that came after that.
- You then mount the Database in Exchange. The database will go up to where the log file you restore says to, but it will stop at the last log file that precedes the location indicated in the summary log file.
- After that, you have a database that has as much mail as possible in the deleted mailbox. You can then restore the mail normally.
DAG (Database Availability Group)
Database Availability Group is a group of 2 to 16 mailbox servers that host a set of databases. DAG automates database-level recovery from individual servers or databases, as well as network failures. Each server that is a member of the DAG is capable of hosting active or passive copies of mailbox databases that reside on servers in the group.
All servers in a DAG should be running the same Exchange version. For instance, you can't have Exchange 2010 servers and Exchange 2016 servers in the DAG together.
Exchange Server 2010 Database Availability Group Example
Exchange Online: the Future of MS Exchange Server
In some cases, a hosted Exchange server can be costly and challenging to support. Thus, many organizations choose to use third-party hosted applications to make maintenance easier.
Microsoft Office 365 suite is a hosted, online version of the traditional installed Microsoft Office software. It includes Exchange Online, a hosted messaging platform that offers the full functionality of the Exchange server.
Exchange Online services are accessed across an organization’s wide area network (WAN). When you use this option, there are no Exchange Server software packages to deploy, and no physical servers required for support. This significantly reduces maintenance costs.
Other benefits of Exchange Online are the Microsoft 99% uptime guarantee, predictable costs (you usually pay per user in Exchange Online) and high availability and remote access for user devices including desktops, laptops, netbooks, tablets, and Apple systems.
On the other hand, Exchange Online is not the best choice if administrators want to control the whole infrastructure by themselves. Many users choose to run Exchange on-premise because this option provides full control over security and compliance. It also allows full freedom to customize the server to meet company requirements and reduce ongoing costs.
For a more comprehensive comparison of Exchange Online and Exchange On-Premises, please refer to our corresponding blog post.
Further reading Exchange Online vs. Exchange On-Premises
Simple. Reliable.
