In the first part of this series, we covered the backup options for SharePoint within the AWS cloud. Those of you who work with production servers understand the need for automated backups in order to achieve better consistency and high availability, as well as to avoid manual errors. This is where our Cloud Protection Manager (CPM) comes in handy. As an enterprise-class backup, recovery and DR solution for AWS EC2, EBS and RDS, CPM is available as an AMI in AWS Marketplace. Following part 1 of this series, in this article, we will demonstrate how easy it is to configure and schedule consistent backups for your SharePoint server as well as restore the data with CPM.
First, let’s review how SharePoint is setup:
For this article, we have created an example SharePoint site and a few blogs to demonstrate how the backup and recovery processes work. First, we installed SharePoint on a Windows 2008 server and created an additional volume (D – Drive) with 50GB to hold our SharePoint content.
Below are our example blog posts: After your setup is complete, you can schedule a backup. As discussed in part 1, snapshots are the best option for backup/restore in SharePoint, and can be automated using CPM.
Setting up CPM
CPM allows you to create backup policies and schedules. These are used to identify the objects (instances/volumes/RDS) you want to backup and schedule when backups should be performed. Below, you can see the AWS account credentials that we used to set up our CPM account. It is recommended to create an IAM login with AWS that holds the required permissions instead of providing your root account credentials. Backup Schedule: The CPM backup schedule allows you to set up your backups for specific weeks/days/hours/minutes. As seen below, we have scheduled a backup to be executed in CPM every day, every four hours. Backup Policy: The backup policy is the backbone of CPM. It defines logical groupings of objects (backup targets) that should be backed up together, such as EC2 instances, EBS snapshots/volumes, and RDS instances. Additionally, it determines whether backup scripts, DR policies, and other various options should be used. The backup policy we have created below is linked to the schedule that we created above. In this case, our backup target is the AWS instance on which we have set up SharePoint. There is no need to set up EBS volumes individually if you have multiple EBS volumes that are attached to a single instance, CPM will take care of that.
The CPM Thin Backup Agent
Once setup is complete, CPM will begin taking snapshots at regular intervals using CPM’s Thin Backup Agent. By performing quiescing with VSS, the agent ensures that backups are consistent. This is an important advantage that CPM has over other solutions. The clear advantage here is that no manual intervention is required. All backups will simply be performed as scheduled.
What good is a backup if it cannot be quickly restored? In the example below, we tested CPM’s restore option by creating a new blog after a snapshot was taken. To recover data from an existing instance, you should launch a new instance from the same AMI (the one used to launch the original instance or an AMI with the same OS), then stop the instance. Next, click on the ‘Recover’ button, select all volumes as the recovery option, and attach the stopped instance to those volumes.
When you start the stopped instance, you will be ready to use the restored data. Below, you can see both of my instances (the original instance and the one restored from the backup). The blog will show the same as the output taken before snapshot.
It is clear that AWS provides the best possible solution for backup and recovery. However, using CPM simply makes life easier. By providing an efficient way to regularly back up your system, CPM ensures consistency using VSS, which is crucial for critical production environments, and quickly restores data.