What is SharePoint?
SharePoint is an Enterprise Content Management (ECM) portal that was developed by Microsoft. As a web-based system, it can be hosted on-premises or in the cloud and is primarily used to centralize, version, share, and manage content across a workgroup.
Why Deploy SharePoint in the Cloud?
Despite its versatility, it is advantageous to deploy SharePoint in the cloud due to features such as scalability, on-demand resource availability, and a cost-effective pricing model. Utilizing Amazon EC2 lets ready-to-use Amazon Machine Images (AMIs) reduce an environment’s setup overhead efforts and provides more efficient backup and restore options. Overall, SharePoint is deemed one of the most important collaboration tools across companies and organizations of all sizes.
Therefore, it is important that it is set up with high availability and scalability in mind. A generic scalable SharePoint farm consists of web & application servers (IIS) for all incoming requests, crawling and administrative requests, as well as application roles and services. It also includes an MSSQL database to hold content, conduct searches, and perform other SharePoint site management data operations. In this two-part series, we will discuss three backup and restore processes that can be implemented with SharePoint.
Backing up an AWS-hosted SharePoint
We’ll first look at how the built-in options compare to the standard backup and restore processes available in an AWS-hosted SharePoint environment. Then we will discuss the new challenges associated with backup and recovery in cloud-based SharePoint environments. Finally, we will explore the backup mechanisms and PowerShell commands that are used to backup SharePoint environments. Two of the major concerns of hosting data on a SharePoint server are ensuring continuous availability and all-inclusive data consistency.
In order to achieve these, setting up a plan to back up data periodically will help prevent data loss due to unavoidable circumstances or human error. There are several backup and recovery options available with SharePoint, which can be selected, as needed, based on the size of the dataset, backup time, type of backup, and maintenance procedures. Backup can be performed on a myriad of components, including content databases, configuration files, site collections, as well as documents.
The SharePoint Farm Built-In Backup and Restore Processes
Backup
This option backs up configuration files, central admin content databases, and search service index files, then integrates them with the search service database. The complete backed up SharePoint farm can be recreated on new hardware, however a backup created for one version cannot be directly used for another version. The maximum size supported for this backup option is around 200GB, which does affect server performance.
The PowerShell command for SharePoint farm backup is as follows:
Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} [-Verbose]Below are the parameters for the command above:
- <Backup Folder> Folder on a local computer/network for backup. It is advised to have a local backup for faster performance.
- BackupMethod – The backup process, although one full backup is required before differential backup.
Restore
Farm recovery is performed in the event of total farm failure. Partial backups are not possible, and as mentioned above, one backup version cannot be restored to another version. Additionally, applications need to be manually started after the recovery process is complete.
The PowerShell command for SharePoint farm recovery is:
Restore-SPFarm -Directory <BackupFolder> -RestoreMethod Overwrite [-BackupId <GUID>]SharePoint Granular Backup and Restore:
Backup
This option includes site collection backup and export, lists, and document libraries. It is more read and process intensive than farm backup, as it uses SQL transaction queries and export calls.
It can also use SQL server database snapshots to maintain data consistency and allows users to interact with site collection when backup is in process. Users are advised to use this backup option for up to 85 GB of data.
The PowerShell command for site collection backup is:
Backup-SPSite -Identity <SiteCollectionGUIDorURL> -Path <BackupFile> [-Force] [-NoSiteLock] [-UseSqlSnapshot] [-Verbose]Below are the parameters for the command above:
- <SiteCollectionGUIDorURL> is the ID or URL for the site collection you want to back up.
- <BackupFile> is the path leading to the location of the backed-up file.
- –Force overwrites the previous backup file.
- –NoSiteLock prevents the read-only flag from being set during backup operations.
- -UseSqlSnapshot is available for the SQL Server Enterprise edition and is advised to be used to ensure data consistency.
Example:
Backup-SPSite http://mysite.acount.com/ -Path C:\Backup\mysite_backup.bakRestore
Granular backup can only be restored through PowerShell because the central admin is not available here.
The command to restore the backup is:
Restore-SPSite -Identity <SiteCollectionURL> -Path <Backup file> [-DatabaseServer <DatabaseServerName>] [-DatabaseName <ContentDatabaseName>] [-HostHeader <Host header>] [-Force] [-GradualDelete] [-Verbose]Limitations of the SharePoint Built-In Backup and Restore Processes
While the built-in options described above are quite impressive, a number of challenges do exist:
- The restore process is time consuming.
- The 200GB and 100GB size limitations for farm and site collections can be restrictive.
- Server performance is affected during the backup process, requiring a backup schedule plan.
- Backing up and restoring individual items is not possible.
- Backup and restore involving different versions of SharePoint are not supported.
- Making changes offline will most likely result in data loss.
- Changes can only be made to SharePoint farms using the SharePoint Object Model during a granular backup; attempts to make changes with external tools could result in limited farm access.
- Changes made to the object model can affect backup performance.
- There are specific servers/instances for backup and recovery.
- Offshore backup is no easy feat.
- Maintaining data spanning several points in time and versions is not a real option.
SharePoint on AWS
SharePoint servers can be easily deployed on AWS, which makes the backup and data recovery process a breeze. You can use EBS backed AMIs to launch a Windows EC2 instance to run your SharePoint application. Additionally, you can provide your own SharePoint license under License Mobility through Microsoft’s Software Assurance program.
If you do not want to set up SharePoint on your own in AWS, you can use an AMI, provided by Microsoft, in AWS Marketplace, that is based on the pay-as-you-go license model. There are numerous advantages of utilizing SharePoint on AWS EC2, such as cost optimization, a scalable infrastructure, a flexible development model, secure access, high availability, and effortless management.
Whether you have a complex setup, such as the one above, or a simple setup with two application servers and one database server, your backup process needs to take high availability and disaster recovery into consideration.
Generally, with AWS, you have to backup your database servers along with your application and web servers, site, and farm for quick recovery.
3 EC2 capabilities that can support backup and restore in a SharePoint environment
1. Storing Backup Objects on S3
In order to store backed-up objects, you have to use the built-in backup and recovery mechanism that comes with SharePoint, along with a SQL server using Microsoft tools. The methods discussed above can be put in action by running the commands on their respective EC2 instances.
Backup can be performed according to Microsoft’s guidelines and backup files can be stored in AWS S3 on a regular basis. While this is a generic SharePoint backup, you should backup and store all related components and services in AWS S3, including the farm level database and configuration with SharePoint Data Protection Manager.
AWS S3 is a highly scalable and durable object-based storage service. Since it doesn’t contain the Windows file system interface, it solely serves the purpose of a storage service. This may be a time-consuming procedure, as it involves all of the steps in the SharePoint backup process and is still restricted by the limitations mentioned above.
You can use AWS APIs to automate data that is uploaded to AWS S3, with the added advantage of leveraging highly durable, unlimited, cost-effective, and secure online storage.
2. EBS Backed AMIs
Another option is to create an AMI from the running EC2 instances where SharePoint is deployed. The AMI creation process is a one-step process (right click on an instance ⇒ Create AMI) for EBS backed instances and is a good option when making SharePoint configuration changes. The backup process creates and registers images and snapshots of volumes that are associated with the process.
The only challenge here is that the instance at hand may need to be rebooted, meaning it would not be available for a few minutes. That could harm data consistency during backup. It is recommended to create an AMI during off-peak hours or from your backup server.
You can also reduce backup times by taking snapshots of volumes just before image creation. Instance reset can be avoided explicitly if the user is sure that the instance is consistent for image creation.
AMI backup is important for all web/application servers, in general, and can be performed only if there are no frequent changes made to site configuration once it is set up. Furthermore, it is important to note that in a multiple instance environment, such as SharePoint, all AMI creation may not be done at the exact same time. These can harm the consistency and continuity of the environment as a whole.
We strongly recommend you learn more about how to backup and recover EC2 Windows instances
Once an AMI is created, it will backup the root EBS volume and create a snapshot of the image. You can always launch a new instance in the future that will have all of the data and configurations available from when the AMI was created. In the image above, we launched a Windows AMI, then configured SharePoint on it. Once you create an AMI, you can always launch a new instance that will have Windows SharePoint installed and configured.
3. Snapshots of EBS Volumes:
One of the best options for backup and recovery is AWS EBS volume snapshots. An EBS snapshot is a point-in-time, incremental copy of an EBS volume that is stored in AWS S3. AWS only copies modified EBS blocks, which helps speed up the process and saves on redundant data expenses.
This process is asynchronous so end users can continue using an application while snapshots are being taken, without any major performance impacts or data inconsistencies.
Learn how EBS snapshots and restore really work
Seeing as EBS snapshots are stored in AWS S3, they are highly durable and make for an easy recovery process. It is advised to take periodic snapshots based on your application’s RPO and RTO. If your application fails for any reason, users can create a new volume from the stored snapshots and attach it to an EC2 instance (as the root /additional device).
Since snapshots are taken at a specific point in time, any data that was on the disk at a particular moment will be available when that respective snapshot is restored.
In an enterprise environment, such as SharePoint, it is crucial to maintain consistency, which includes taking snapshots of volumes at the same point in time, and building an automated backup and recovery process. This aspect will be explored further in part 2 of this series.
EBS snapshots are used for other purposes, as well, such as restoring a larger volume size, creating a new volume in another availability zone, and copying snapshots to another region in order to create a volume for high availability.
Additionally, an automated solution would help in automating the recovery process. All of these actions need to be kept in mind and leveraged when building an automatic backup and recovery mechanism within EC2.
The Benefits of SharePoint Backup on AWS
- Fast snapshot-based backup and recovery (in a matter of minutes)
- Cost-effective and quick incremental backup
- Unlimited capacity with the option of making multiple 1TB EBS volumes into one logical volume that can be backed up with snapshots
- Easy volume size adjustments using snapshots
- Snapshot creation in different zones/regions, ensuring high availability and disaster recovery
- AWS API automation based on defined RPO and RTO
- The ability to take snapshots of a particular point in time and restore to that specific point
There is no doubt that with the introduction of the cloud, enterprises have greatly benefited from the increased flexibility and lower costs of backup and recovery processes.
2 important features supported in automated backup and recovery on AWS
The first is the ability to take snapshots of the data to be backed up, as well as the application, in general, at a specific point in time. The second leverages AWS global footprint in order to maintain offshore backup. However, with these great benefits, come new challenges, such as environment management and automation.
It is no longer about buys and deploying actual servers, but about coding and building your disaster recovery policies on top of AWS APIs. In part 2, we will delve deep into the methods and tools needed to help keep backup consistent all the way to replicate your whole SharePoint environment from scratch in another region.
