The Commvault 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.
Commvault 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 Commvault 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:
Amazon EC2 Backup Using Amazon EBS Direct APIs
Commvault 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. For more information about CBT for AWS, see Changed Block Tracking for AWS.
Important: Commvault does not support use of Federal Information Processing Standard (FIPS) service endpoints to secure data transfer or data at-rest when protecting FIPS-enabled AWS services. For information see Federal Information Processing Standard (FIPS) 140-2 on the AWS website.
Job Statuses for Backup Copy Operations
For Feature Release 19 and more recent feature releases, when an IntelliSnap backup includes multiple VMs, if a backup copy job for a specific VM cannot be completed, the backup copy job goes to pending and then retries the backup copy operation, up to the maximum number of job attempts that is configured for the Job Manager. (By default, the number of job attempts is 10.)
Any backup copy jobs that do not complete successfully after the maximum number of attempts are marked as Completed with Errors. If backup copy jobs for any VMs do not complete successfully after the maximum number of attempts, the associated IntelliSnap backup job is marked as Completed with Errors.
For service packs prior to Feature Release 19, if a backup copy operation was successful for any VM in an IntelliSnap backup job, the IntelliSnap backup job was marked as Completed with Errors if backup copy operations were unsuccessful for other VMs that were part of the IntelliSnap backup job, and any unsuccessful backup copy operations for the remaining VMs were not retried.