When conducting data protection boot camps and office hours sessions, I’m frequently asked about data protection and recovery in the Amazon Web Services (AWS) public cloud. While the official answer is that AWS is not a platform we develop for, test, or officially support, I am happy to say that, due to the hardware abstraction of virtualization platforms, we have partners who are successfully protecting systems hosted and running on the AWS EC2 platform. In this blog post I’ll outline how those partners are deploying, configuring, and restoring data with N-able™ Backup.
Let me begin by stating that N-able Backup is not natively aware of AWS and does not interact with AWS directly. To offer data protection for AWS, you must install N-able backup manager, the backup client software, locally within the guest operating system. In this type of deployment, backup manager has no awareness of the host hypervisor and behaves just as it would if it were running on a physical system. You can install the backup client manually within the guest operating system or via scripts and automation as discussed in this blog post. You could even go as far as to include a partially configured instance of N-able Backup in a custom AWS AMI. However, downloading and deploying with the latest version seems to be the most common practice. When provisioning an AWS instance that will run a local backup manager client, you should avoid single core instance configurations and ensure that the backup manager has access to at least 500Mb of available free memory.
Recurring data protection for AWS hosted systems will typically function normally with access to all the same backup features, plans, policies, and profiles that are available to physical systems. However, I should clarify that N-able Backup does not store your encrypted backup data within the AWS infrastructure. All backup data is sent off-site to a regional N-able data center. AWS may charge for data egress from their infrastructure. To help reduce the data transfer in and out of AWS, I typically suggest partners layer their data protection by using a combination of AWS EBS snapshots for local protection and rapid recovery, and N-able Backup for off-site protection and long-term archival.
Traditional, file, folder, application, and volume level restore options are also available from within the backup manager. You can quickly use them to help correct a user error, accidental deletion, corruption, and even ransomware. However, advanced recovery tools like bare metal recovery, virtual disaster recovery and the recovery console are not able to restore directly to AWS native installations. Situations requiring full recovery of the AWS instance may require the combined efforts of deploying from an AMI or reverting to the most recent full EBS snapshot and then using backup manager to selectively restore data and applications to the desired point in time.
While a direct virtual disaster recovery (VDR) to AWS is not possible, VDR of many systems can be performed locally to VMware and Hyper-V hypervisor, or offline to VMDK and VHD\VDHX files that can then be loaded back into AWS as an image using the following Import VM as Amazon Machine Image (AMI) process. There are a series of prerequisites and steps to follow, including creating an S3 bucket to house the uploaded image and an import process to test and convert that image to an AMI, which you can use to redeploy a new instance of your restored machine.
Eric Harless is the Head Backup Nerd at N-able. Eric has worked with N-able Backup since 2013 and has 25+ years of data protection industry experience in sales, support, marketing, systems engineering, and product management. You can follow Eric on Twitter at @backup_nerd