(: August 29, 2019)
Image source: Pixabay
The ease with which you can backup and restore data may not be your greatest consideration when it comes to choosing cloud providers until you experience your first data loss or corrupted instance, of course. Once that happens, you might wish that you had paid a bit more attention to your options.
To help you avoid getting caught off guard, we’ll look at what backup services are available in Azure and AWS and what your options are for automating the process.
Azure vs AWS
Both Azure and AWS offer a few different methods for creating and managing backups and each has a few different ways to automate the process.
Azure offers two options for backup: restore points and snapshots. Restore points are traditional backups that can be used to restore entire Virtual Machines (VMs), databases, or individual files. They are created through Azure Backup service and stored in a Recovery Services vault. Snapshots are point-in-time, application-consistent backups that can be used to restore an entire VM or as an image from which to create new VMs. They can be created manually or through a separate service called the StorSimple Snapshot Manager.
For Azure, snapshots are preferred when upgrading VMs or when you need to create new VMs based on an existing template but restore points through Backup are the recommended solution so that’s what we’ll focus on here.
Azure Backup facilitates both on-premise data duplication to the cloud and in cloud duplication. With it, you are not charged for data transfer during either backup or restoration, only for the storage that is used. There is no time limit on how long backups can be kept and you are allowed to store up to 9999 recovery points per instance. Azure Backup allows you to store your recovery points in either Locally Redundant Storage (LRS), with three replications in one region to protect from local hardware failures, or in Geo Redundant Storage (GRS), which replicates to a secondary region. This service can automatically encrypt your backup data at rest.
Management and Automation in Azure
You can create and manage your backups on Azure in three main ways, allowing you to easily fit Backup into your existing operational workflows: the Azure Portal, PowerShell, or Command Line Interface (CLI).
Azure Portal is a browser-based interface from which you can centrally control your Azure connected services. It has a simple user console from which you can access support, monitor resources, and configure your system. In the portal, you can relatively easily create backup policies, one per VM, in which you can schedule backups and specify lifecycle information, such as how many restore points to keep and how long to keep them for.
The PowerShell and the CLI, in Azure this is a browser-based service called Azure Cloud Shell, work the same as you’re used to and can be used to more finely manage restoration points and automation through custom scripting and API calls. If you wish to automate in this way, you will need to create an Automation Account, import the appropriate modules, create a Runbook specifying the VMs you want to target and assign the Runbook to the Automation Account.
A full walkthrough of the process of building an automation Runbook for Azure can be found here.
AWS snapshots are a bit different than Azure ones and are used as the primary method of backup for AWS instances, although they can also be used for instance creation. Snapshots can be created manually or managed through AWS services. Until recently, Lifecycle Manager was the best option for this but the introduction of AWS Backup has changed this.
AWS Backup is a fully managed, centralized service that can be used to manage and automate backups of on-premise and cloud services. Previously, each service only had service-specific backup methods, which can still be used, but now the most commonly used services are all covered by AWS Backup.
Using Backup itself doesn’t cost but you will be charged a varying rate, depending on the service being backed up, for the data transferred during snapshot creation as well as for the storage the snapshot itself uses. The snapshots created can be stored directly in some of the services they are backing up, or in the default location, S3.
Whether your data is stored in separate regions or availability zones, to ensure availability and disaster recovery, will depend on your configuration. This service can automatically encrypt your backup data both at-rest and in-transit.
Management and Automation in AWS
Through the AWS Backup console, you can create backup schedules, including start time, frequency, and backup window, and lifecycle policies based on metadata tags you have applied to your resources, to automate your backup process. From this console, you are also able to monitor your backup jobs and restore data. AWS Backup integrates with AWS CloudTrail to allow backup logging and compliance audits.
With most AWS services, you can more finely automate and manage backups through a combination of custom scripts and either the CLI or Lambda, a service for serverless computing. Using this method, you can script out your backup policy, similar to how a Runbook is used in Azure, and initiate your script through API or service calls to Lambda, or through the use of Cron jobs and the CLI. Doing so requires creating a role with automation permissions, similar to the automation account used by Azure.
You can see example code for accomplishing this automation through Lambda in this tutorial.
Backup methods are probably not “make or break” in your decision of which cloud provider to choose but you need to be aware of them before you commit to a provider. In general, the way that backups are handled in Azure vs AWS are fairly comparable but the subtle difference may be a deciding factor. On the one hand, there is the ability to individually recover files in Azure, and on the other hand, you can manage backups for all your services in one place in AWS.
No matter which service you’re using, make sure that you are backing up your data consistently and reliably to avoid any disastrous data loss. Additionally, it’s probably a good idea to become familiar with custom scripting as both AWS and Azure can be more finely managed when you can effectively access them through API or SDK.