Running Backups for Amazon EC2 Instances


The Metallic software protects Amazon EC2 instances by creating an Amazon hypervisor and associated VM groups, which identify the instances to back up. A VM group has an associated backup plan that defines the backup schedule, storage location, and retention. The plan associated with the AWS hypervisors and VM groups manages scheduled backups. You can also perform on-demand backups.

Metallic can orchestrate the creation of cloud-native Amazon EBS snapshots and Amazon EC2 AMIs as a rapid recovery point when you enable IntelliSnap backup on the VM group. During an IntelliSnap backup, the Metallic software orchestrates and manages the creation of an Amazon Machine Image (AMI) and the associated Amazon EBS snapshots, which are retained per the retention settings in the backup plan. If an Amazon EC2 instance fails to create an Amazon Machine Image (AMI) during an IntelliSnap backup of a VM group, the backup job is marked as completed with errors.

To back up Amazon EC2 instances that have UEFI boot mode enabled, there must be at least one UEFI-enabled AMI present in the AWS account performing the backup. If a UEFI boot enabled AMI is not present, the backup will fail.

For more information, see the following:

Changed Block Tracking (CBT) Based Backups

Metallic uses Amazon EBS direct APIs to perform Change Block Tracking (CBT) backups of Amazon EC2 instances and associated Amazon EBS volumes. Amazon EBS direct APIs accelerate back up activity by identifying changes between two Amazon EBS snapshots by using the API. You can use Amazon EBS direct APIs or Change Block Tracking with streaming backups, and with the backup copy operation of IntelliSnap backups. By default, CBT is enabled when you create a new AWS hypervisor VM group. You can also enable CBT for existing VM groups.

Synthetic Full Backups

Synthetic full backups consolidate the data from the latest full backup or synthetic full backup with any subsequent incremental backups, instead of reading and backing up data directly from the client computer. Because synthetic full backups do not back up data from the client computer, this operation imposes no load on the client computer.

During a synthetic full backup, a list of objects from previous backups is generated, and the latest version of each object is considered, in order to build new backup image. Furthermore, using extended retention settings for a subclient, synthetic full backups can also retain deleted or older versions of objects.

Advantages of Synthetic Full Backups Over Full Backups

Synthetic full backups have the following advantages over full backups:

  • They impose a lighter load on the production environment because they are created by consolidated data from the backup repository, rather than from the client computer.

  • They have the ability to carry forward older or deleted versions of the objects backed up during the previous backup cycles.

Note: Using synthetic full backups can cause unintentional expiration of data since retention periods are defined by the number of full backup cycles. For example, running a synthetic full immediately after a standard full backup does not consolidate any data (as the standard full already includes all the backup data); storage resources might be unnecessarily consumed.