Amazon EC2
Last updated
Last updated
Storware Backup & Recovery supports the Amazon EC2 cloud platform by using a VM called “Proxy VM”. The node invokes commands on the AWS to snapshot and attach EBS drives of a specific VM to itself (Proxy VM). The proxy VM is able to read the data from the attached disk snapshots and forward them to the backup provider.
This means that you need to create an EC2 instance (Proxy VM) in each zone.
The Storware Backup & Recovery Server can be deployed anywhere, but keep in mind that Nodes need to be able to call the server over HTTP(S) on the port you have specified.
The AWS backup strategy allows you to exclude drives from the backup that you don’t need. Remember that you need to install 1 Proxy VM per AWS zone so that drives that the Node tries to attach are reachable.
All backup destinations can be used, but keep in mind that you may be charged for transferring data between regions, AZs, and external backup providers.
Storware Backup & Recovery Node has access to instances only in the zone where it is hosted.
Storware Backup & Recovery Node requires the account ID, access key, and secret key to connect to the AWS account.
There are several scenarios for AWS which may be suitable for your case:
Backup EC2 to S3 - in this case after dumping backup, Storware Backup & Recovery can push them to the S3 bucket. You may consider using a VPC endpoint to boost your store's operating performance.
Backup EC2 to EBS volume on the proxy - you can use PowerProtect DD to deduplicate data and optimize your storage consumption significantly. Keep in mind that you may want to protect your EBS volume using EBS snapshots as well.
Backup EC2 to your local backup provider - if you already have a central enterprise backup solution, you may want to use it as a backup provider for EC2 instances running in AWS. You should consider using Direct connect to have a higher bandwidth available.
Backup EC2 to your other cloud provider - If you're using multiple clouds, you also may consider storing data in GCS or Azure backup providers.
Note: In all cases, depending on your target, you may be charged for data transfers.
It is assumed that you have working experience with Amazon EC2 to be able to deploy Storware Backup & Recovery components. You also need to have an IAM user with permissions that allow you to deploy an instance and generate access/secret keys for Storware Backup & Recovery.
Remember to use CentOS 8 AMI as a base image - both for the Server and Nodes. For a typical installation, we recommend 2 virtual processors and 8 GB of RAM. This means that t3.medium or m5.large should cover general use cases. For better performance, however, we recommend using storage optimized instances such as i3.large or bigger, where I/O intensive operations should perform better.
Both Storware Backup & Recovery components are assumed to be deployed without HA (more precisely, all the nodes or server will probably be in separate AZs, and only need to communicate over HTTP). There is no requirement for multi-AZ deployment for now. While the Node is stateless and can be lost without data loss, the Server needs DB to be protected. Storware Backup & Recovery provides a built-in automatic DB backup mechanism, which can be used to protect backup metadata. Please refer to the Disaster recovery section for more details.
From a networking perspective, Storware Backup & Recovery requires communicating with Amazon EC2 API, but it is still recommended to put in a private subnet and allow communication over a NAT Gateway.
You add Amazon EC2 as a Hypervisor Manager. You need to provide the account ID and access/secret keys of a user that has permissions to handle snapshot, AMI and EBS volume operations, and EC2 instance creation.
On the same screen, you also specify if the AMIs of root volumes should be created during the backup process. For Windows instances, we recommend also keeping an AMI image with each backup to have the option to restore the original root volume as well. You can also skip AMI creation, but this means that during restore you need to specify the appropriate AMI ID that you want to boot from.
Here are the IAM permissions that Storware Backup & Recovery needs to have for backup/restore operations.
To properly configure your AWS account, go to Storware Backup & Recovery WebUI -> Virtual Environments -> Infrastructure -> add hypervisor manager
Enter parameters such as:
Account ID
Access key
Secret Key
Enable/disable Windows, Linux image
Note: When Storware Backup & Recovery creates a backup, some operating systems, such as Windows, may require an AMI for later restores in order to keep your OS settings. With this option, Storware Backup & Recovery will keep the AMI necessary for future restores in your AWS account. Without this image, a new instance will have to be started with a fresh root device and additional volumes attached, which may not contain your OS-related settings, licenses, or data that were stored on the root device.
These settings regarding Windows or Linux images are required to define the way backups and restores are done. AWS supports 2 ways:
Using AMI and AWS snapshots:
During Export or Snapshot tasks an AMI is created for the root volume, other volumes are snapshotted.
The AMI is stored in AWS until Storware Backup & Recovery snapshot or backup removal is initiated.
During Restore, a new instance is launched from a previously exported AMI, and imported non-root volumes are attached.
Using AWS snapshots:
During Export or Snapshot tasks, all volumes are snapshotted.
During Restore, an AMI is created from the imported root volume, a new instance is launched and imported non-root volumes are attached. The AMI is then removed.
In both cases, volume snapshots are kept in AWS only if the Storware Backup & Recovery Snapshot task is completed.
Note: A Windows AMI created from a snapshot is not launchable, hence it is recommended to enable using AMI for the Windows platform.
AWS supports two backup and restore strategies:
Disk attachment (full)
Disk attachment with changed block tracking (full/incremental)
It is possible to specify another AMI for attaching non-root volumes during restore. You can also specify an availability zone for a new instance.
To secure instances from multiple zones and regions, you need to register additional Storware Backup & Recovery Nodes. For every zone you want to backup instances from, you need to create separate Node Configuration. Each Node Configuration needs to be assigned to correct Hypervisor Cluster (which reflects compute zone from AWS).
First synchronization task needs only one Node. After first scan, you can assign Node Configurations to Hypervisor Clusters, and run synchronization task once again to fetch all instances from other zones.
To assign Node Configuration to Hypervisor Cluster, go to Clusters list in Infrastructure tab. Next, click on selected Cluster to choose Node Configuration.
Note: For backup and restore between zones, nodes and node configurations should have access to the same backup destination.
From the AWS perspective, you need to take inot account several additional costs that may be incurred:
EC2 instance costs for the Storware Backup & Recovery Server and Nodes:
depends on the number of nodes (assume at least one node per zone)
to reduce costs we recommend using use reserved instances for production use
Backup destination and staging space storage on EBS:
staging space is necessary and we recommend it to be at least the size of the biggest VM multiplied by the number of export and store threads
if you want to store backups on EBS you also need to have additional storage
you can have both using the same EBS volume
we encourage you to use deduplication, as it may even result in over 95% of storage savings
Data transfer costs:
if you upload data to external backup providers, or if a node needs to transfer a lot of data between AZs - this can be reduced by deploying one node per AZ
