It is imperative to understand what would be at stake if your Exchange Server was compromised. Data is the primary at-risk component in these situations, but service interruptions also hamper business continuity. Such incidents are unavoidable, so it is better to be prepared.
In this guide, we will discuss some best practices for creating a backup restore and recovery strategy to quickly repair Exchange Server data and services if disaster strikes.
Best Practices
Here are some practices that you can follow when preparing a backup restore and recovery plan in Exchange Server.
1. Understanding Exchange Server Backup and Recovery Concepts
a. Exchange Server Architecture
In Exchange Server, the configuration is stored in the Active Directory (AD) Schema. Data is stored in the databases, along with the transaction logs. Exchange Server has a Mailbox Role, which is responsible for the management and upkeep of the database and transport services to deliver emails and data. The Edge Server can be set up in the perimeter network as another wall between the internet and internal services.
b. Understanding Backup Types
It’s important that the Active Directory and the databases be backed up. When it comes to recovery, you should have the same instance of the Active Directory server and the Exchange Server, as data/configuration might be lost if not in sync.
Let’s understand the three backup types you can use in your setup:
- Full Backup: This backup will create a copy of the entire machine, including the transaction logs and databases. Each backup is taken as a new one, which means that it is independent from any previous backup as it holds all the data in the same backup. However, taking this type of backup will require a lot of time and storage. It would impact the performance of the server if done multiple times during the day.
- Incremental Backup: In this instance, a full backup is taken on the first run, as well as a backup of only the changes from the previous run. This type of backup is fast, and the data transfer is minimal, as it only takes the backup of the changes. However, each and every backup is dependent on the previous one.
- Differential Backup: This backup is similar to the incremental backup. However, the only difference is that instead of backing up the changes from the previous backup, it backs up the changes from the (first) full backup. This means that the differential backup is only dependent on the full backup, thus reducing the risk. However, it takes more storage and time to complete.
c. Understanding Recovery Models
In Point-in-Time Recovery, you can restore the data to a specific time using transaction logs to replay any changes done, forward or backward.
In Database Recovery, you can restore the entire Exchange database from backup and then restore the mailboxes manually.
In Mailbox and Item-Level Recovery, you can recover individual mailboxes or items via Recovery Database (RDB) or third-party tools.
2. Developing a Backup Strategy for Exchange Server
a. Assessing the Organization's Needs
Depending on the nature of your business and the data's criticality, you need to comply with legal obligations and regulations. These can be measured using:
- Recovery Point Objective (RPO): This states the maximum acceptable amount of data loss the organization can suffer. The organization can define how much data it can afford to lose and still maintain its business continuity.
- Recovery Time Objective (RTO): This defines the maximum amount of time critical services can be down. If the RTO is 4 hours, for example, there is a limit of 4 hours from the initial disaster to when the business can operate again and restore its services.
Due to user load, mailbox size, and dependency on email services, it is important to evaluate mailbox sizes and user activity from time to time. This will help in anticipating data growth and introducing archiving and retention policies. It will also reduce recovery time when disaster strikes.
b. Selecting Backup Solutions
The Windows Server Backup is a consideration when backing up the Exchange Server. However, you should also look at the backup's limitations. These include no encryption, no offsite backups, no replication, and no support for tape libraries or cloud storage.
You can also consider third-party backup tools, such as Acronis Cyber Protect, Veeam, and Altaro. These backup solutions feature vast integrations with virtual environments, immutable storage to protect against malware or ransomware, offsite backups, encryption, replication, failover possibilities, and Continuous Data Protection (CDP).
When purchasing a third-party backup tool, you should consider the features, like offsite backups and replication. It is also important to check with the supplier or vendor that the backup tool is compatible with your Exchange Server version and the operating system.
c. Determining Backup Frequency and Retention
Time is an important consideration when executing the backup. It would be taken in off-peak hours or during maintenance windows during the night. If the performance of the server is at a limit, you should consider upgrading the server if you opt for more frequent backups during the day.
As mentioned earlier, depending on the nature of the business and legal compliance obligations, you need to retain backups for a certain amount of time. You should also consider the cost and resources of keeping the data and securing it.
d. Verification and Testing
After creating a backup, it’s imperative to monitor the backup on a daily basis. This will ensure that the backup is taken at the scheduled time. You should also perform restore tests on a monthly basis to ensure that the backup can be restored with no issues when the need arises. A full disaster recovery restore in a sandbox environment should be performed once a year.
When having a backup job on an Exchange Server, you should monitor and keep an eye on the storage. Transaction logs are automatically purged from storage once a healthy backup is taken. If these are not purged, you could end up with no storage and damaged or corrupted data.
3. Exchange Server Restore and Recovery Options
a. Restoring Exchange Server Components
Database-Level Recovery is the process to restore a mailbox database to a specific point in time using the Recovery Database (RDB). To do this, you need to create an empty recovery database, restore the database, mount it, and use the New-MailboxRestoreRequest command to extract the data from the recovered database. Then, you can merge the data with the original mailbox.
b. Performing Mailbox and Item-Level Recovery
You can also use the Recovery Databases (RDB) to recover the entire mailbox or individual emails. Alternatively, you can rely on a third-party professional Exchange Server recovery tool, like Stellar Repair for Exchange, for a smooth and granular recovery process. This powerful tool allows you to open offline databases from any version of Exchange Server and granularly export the recovered mailboxes, archives, shared mailboxes, disabled mailboxes, purged/deleted items, and public folders to PST, live Exchange Server databases, and Microsoft 365 with complete data integrity.
c. Performing Disaster Recovery
When a disaster happens and the server fails, there are considerations beyond the Exchange Server. The recovery of Active Directory and other features, such as DNS, is imperative. If you have a Database Availability Group (DAG) setup, you should consider the steps needed for setting up cross-site resilience and recovery processes. In addition, you should always put a server in maintenance mode when working on it to ensure that it doesn’t affect the rest of the nodes.
4. Disaster Recovery Planning
You must run an impact assessment to analyze your risk. Prepare a plan to mitigate each and every risk and to restore affected data and services.
To maintain business continuity, you should have an offsite backup or backup on cloud storage. If you’re planning for business resilience and business continuity, you can consider Database Availability Group (DAG) for the Exchange Server clustering.
5. Troubleshooting Backup and Recovery Issues
Some common issues that you might encounter when running a backup or recovery process are:
- Backups Failure: This is a very good indicator of an issue with storage, permissions, or throughput. You can troubleshoot it depending on the cause.
- Log Truncation Failure: This usually happens if the backup is not compatible with the Exchange Server, is not application aware, or is due to misconfiguration of the backup solution. In such a case, consult your supplier or vendor.
- Database Mount Failure: In case of database mount failure, the first thing to check is the Event Viewer and the Exchange Server logs. These will give you a clear indication of the issue.
There are various practices to consider when preparing an Exchange Server backup restore and recovery plan. These include understanding your Exchange environment, creating timely backups, regularly testing those backups, and preparing detailed documents, among other preparations.
It is also important to have the right Exchange recovery tools in hand to recover data quickly. One such tool is Stellar Repair for Exchange, which can recover mailboxes, archives, shared folders, and other items from a corrupted Exchange database (EDB) file of any size.
