AWS is getting more and more popular with innovative offerings for companies of all sizes. That being said, enterprise adoption has been on the rise as a means of meeting scalable infrastructure needs. In the first article of this series, we discussed the built-in backup and restore process for Microsoft Exchange Server. In production environments, it is critical to minimize your RTO (recovery time objective) so that if a data loss incident occurs, you can restore your complete environment as soon as possible. Also, many users that host their Exchange environment in Amazon EC2 need the ability to recover to other AWS availability zones, regions or accounts.
To address these requirements, we will demonstrate in this article how to backup and instantly restore an Exchange Server hosted on AWS. Setup CPM with EC2 Instance hosting Exchange Server In the first part of the series, we showed you how to use MS Exchange’s inherent backup mechanism to perform backup and restore. In this part, we have set up Exchange Server on an EC2 instance via Windows 2012 with an R2 server. The image below is a sample email inbox for Michael Clarke, that we will use throughout the article.
It is very important to note that AWS offers point-in-time backup with a snapshot mechanism. If automated, the snapshot removes human intervention and ensures regular data backups. With CPM, you can set up automated backups by configuring a backup policy and utilize one-click EBS data recovery. To get started, it’s important to first set up the correct backup policy for your EC2 instance in Cloud Protection Manager (CPM). This provides you with the ability to select various options such as backup scripts, DR policies, and schedules. It also defines logical groupings of objects (backup targets) that should be backed up together, such as EC2 instances [with single or multiple volumes], and RDS instances.
As we have hosted Exchange Server on a Windows instance, it is recommended to enable the VSS (Volume Shadow Copy Service) agent on that instance. VSS is a consistent backup infrastructure for Windows servers. It is very useful for cases that require exact point in time backups across volumes/disks. This is done by VSS notifying MSSQL that it is being backed up, then making sure the backup is consistent across all volumes. Learn more about Volume Shadow Copy Service (VSS).
In order to perform this backup, you must have the VSS backup agent set up as part of the backup options in your policy configuration.
Cloud Protection Manager (CPM) only supports VSS on Windows 2008 or 2012 servers and uses the “System Provider” to perform shadow copies. This process is very simple — when CPM creates a backup, the CPM Thin Backup Agent asks the system provider to create shadow copies of the relevant volumes. In this case, differential copies are created, so the complete data of the volume is not copied, only changes that were made from the time the backup began.
Crash-consistent snapshots will not truncate log files when the transaction is complete. CPM provides consistent application backup, which will automatically truncate the logs.
Once the VSS is setup with the correct key and is successfully executed, it will show the backup status in the backup monitor.
Since the instance has multiple volumes attached to it, CPM will back up all of the volumes after executing the VSS agent. You can check this from the backup event log.
Recover Your Data
Now, let’s assume that the exchange server has lost some data. Returning to our example mailbox, you can see that some of Michael Clarke’s emails have been deleted as a result of this data loss.
Since CPM was setup correctly, it will have the backup (snapshot) available. You can therefore select the stable backup from CPM and simply click recover.
It will show the recovery panel below:
Since this is Windows Instance, it requires you to perform some additional steps before it can be recovered with CPM. These require you to use the instance’s image, be it the original image from which the Exchange Server was launched, or an AMI of the current instance.
You can get the original instance ID from the EC2 Instance console by clicking “Instance”. Be sure to write down this ID.
In the CPM recovery console, click “Recover Instance”, which will bring you to the screen below. Replace the Image ID with the AMI ID from the previous step and uncheck the volumes you want to recover for now. These are additional volumes attached to the instance and will be recovered in later stages.
In some cases, you may need to set a Private IP as well as other advanced details that can be configured with “Advanced Options”.
If you use this process for recovery, it will launch a new instance from the original AMI (you can do this step manually from the EC2 Console, too).
Once the instance is running, stop it.
Next, go to the “CPM Recovery Panel” (by clicking “Recover” in the “Backup Monitor” tab). Select the recover with Volumes option now.
The Recovery Panel lists all the volumes that need to be recovered from the original instance. Select “Switch Attached Volumes and Delete Old Ones” in order to ensure that old volumes are deleted and don’t continue to incur costs. If you are not sure about deleting them, however, you can detach the volumes.
In the “Attach to Instance” option, select the newly launched instance ID where the volumes will be attached for recovery. Then, click on “Recover Volumes”.
This will start the Exchange Server recovery process.
Once the process is complete, it will show a status update:
You can start the new instance (that we launched to recover the volumes) now.
The instance will show all the old data (including lost emails).
Sometimes the recovered volumes fail to start an instance due to a status check failure issue. In which case, we recommend following the processes AWS outlines for generic troubleshooting and specific Windows troubleshooting.
Note: We also recommend testing the steps outlined above before performing a system backup or recovery on your production environment.
The first part of this article showed how backing up an Exchange Server is complicated and requires a Windows Administrator’s level of expertise to perform a successful recovery. AWS offers durable block level storage with EBS volumes that are very useful for data persistence. EBS snapshots are very handy when it comes to backup and recovery, but they pose a challenge when it comes to automated backup in production environments.
Some of these challenges include:
- Remembering to take snapshots at regular intervals.
- Snapshots may not be persistent when there are large or multi-striped EBS volumes. The consistency issue may happen for a single EBS volume, too, with non-committed or in memory data.
- If a number of snapshots are created, their management and cleaning process is cumbersome.
However, CPM makes automated backups and snapshot management much easier. By providing an efficient way to regularly backup your system, CPM ensures that Windows instances stay consistent with VSS, which is crucial for critical production environments and quick data restoration.
Related articles: How-to backup an AWS hosted MS Sharepoint environment