AWS Backup Jobs Test

Use the detailed diagnosis of this measure to know which backup jobs have been created, and to track their status and progress.

To view the details of the pending backup jobs, use the detailed diagnosis of this measure.

Use the detailed diagnosis of this measure to identify the jobs that are currently running, and to continuously track their status and progress.

To know which jobs were canceled / aborted by users, use the detailed diagnosis of this measure

For the complete list of backup jobs that AWS Backup successfully finished, use the detailed diagnosis of this measure.

Ideally, the value of this measure should be 0. A non-zero value is a cause for concern, as it implies that one/more backup jobs have failed. You can use the detailed diagnosis of this measure to identify the jobs that failed and troubleshoot the failure.

Some of the common causes for backup job failures are as follows:

• Scheduling a backup job during or 1 hour before a database resource or 4 hours before or during a Amazon FSx maintenance window or automated backup window, and not using AWS Backup to perform continuous backup for point-in-time restores;

• Creating backups for DynamoDB tables while tables are being created.

• Attempting to create a backup for an Amazon EPS file system while a previous one is still in progress;

• Creating backup jobs for Amazon EBS after its soft quota of 100,000 backups per AWS Region per account is exceeded;

• Not using AWS Backup to manage both Amazon RDS snapshots and continuous backups with point-in-time recovery;

• Initiating a backup job from the Amazon RDS console, which can conflict with an Aurora clusters backup job;

• Scheduling backup jobs for Amazon RDS, as scheduled jobs require KMS access;

When creating a backup plan in AWS Backup, you need to configure a backup 'lifecycle'. The lifecycle defines when a backup is transitioned to cold storage and when it expires. AWS Backup transitions and expires backups automatically according to the lifecycle that you define.

AWS Backup transitions data that is no longer referenced by warm backups, from a high-cost warm storage to low-cost cold storage. Backups that are transitioned to cold storage must be stored in cold storage for a minimum of 90 days. You can however, specify how long, after the minimum 90 days requirement, AWS Backup should store your backups in cold storage. In order to save you storage costs, AWS Backup automatically deletes your backups from cold storage at the end of this period. If for some reason, AWS Backup fails to automatically delete a backup even after it has exceeded its retention period, then the backup status changes to 'expired'.

Ideally therefore, the value 0 is desired for this measure. A non-zero value for this measure implies that one/more backups in cold storage could not be auto-deleted by the AWS Backup lifecycle rule. In such situations, use the detailed diagnosis of this measure to know which recovery points / backups could not be deleted. The most common reason for 'expired' backups is the absence of the permissions necessary for backup deletion. During the lifecycle run, if AWS Backup finds that the original AWS Identity and Access Management (IAM) role that created the recovery point was deleted, or if that IAM role does not have permissions to delete the backup / recovery point, then AWS Backup will fail the deletion and move the backup to the 'expired' state. Expired backups can only be manually deleted using the AWS management console.

Use the detailed diagnosis of this measure to know which copy jobs have been created, and to track their status and progress.

Use the detailed diagnosis of this measure to know which copy jobs are currently running, and to track their status and progress.

For the complete list of copy jobs that AWS Backup successfully finished, use the detailed diagnosis of this measure.

Ideally, the value of this measure should be 0. A non-zero value is a cause for concern, as it implies that one/more copy jobs have failed. You can use the detailed diagnosis of this measure to identify the jobs that failed and troubleshoot the failure.

To troubleshoot a failing cross-account copy, verify the following configurations:

• Verify that your source and destination accounts belong to the same AWS Organization.

• Verify that the resource type supports cross-account copying in the specified AWS Regions.

• Verify the encryption criteria for your source account backup.

• Verify that the source AWS Key Management Service (AWS KMS) key policy allows the destination account.

• Verify that the destination vault access policy allows the source account.

• Verify the AWS Organization tag policy configuration.

Use the detailed diagnosis of this measure to identify the pending restore jobs, and track their status and progress.

Use the detailed diagnosis of this measure to know which restore jobs are currently running, and to track their status and progress.

For the complete list of restore jobs that AWS Backup successfully finished, use the detailed diagnosis of this measure.

Ideally, the value of this measure should be 0. A non-zero value is a cause for concern, as it implies that one/more restore jobs have failed. You can use the detailed diagnosis of this measure to identify the jobs that failed and troubleshoot the failure.

For the complete list of recovery points that are fully created, use the detailed diagnosis of this measure.

A 'Partial' recovery point is created if AWS Backup is unable to fully create the recovery point before the backup window closed. Ideally, there should not be any partial recovery points in a vault. This means that 0 is the desired value for this measure. If the measure reports a non-zero value, it indicates that one/more partial recovery points exist. In such a case, you can use the detailed diagnosis of this measure to identify these recovery points and delete them.

Its good practice to avoid the creation of partial recovery points. This can be achieved by increasing the backup plan window. You can either use the API or the console to update your backup plan.

When creating a backup plan in AWS Backup, you need to configure a backup 'lifecycle'. The lifecycle defines when a backup / recovery point is transitioned to cold storage and when it expires. AWS Backup transitions and expires backups / recovery points automatically according to the lifecycle that you define.

AWS Backup transitions data that is no longer referenced by warm backups, from a high-cost warm storage to low-cost cold storage. Backups / recovery points that are transitioned to cold storage must be stored in cold storage for a minimum of 90 days. You can however, specify how much longer, after the minimum 90 days requirement, AWS Backup should store your recovery points in cold storage. In order to save you storage costs, AWS Backup automatically deletes your recovery points from cold storage at the end of this period. If for some reason, AWS Backup fails to automatically delete a recovery point even after it has exceeded its retention period, then the recovery point status changes to 'expired'.

Ideally therefore, the value 0 is desired for this measure. A non-zero value for this measure implies that one/more recovery points in cold storage could not be auto-deleted by the AWS Backup lifecycle rule. In such situations, use the detailed diagnosis of this measure to know which recovery points could not be deleted. The most common reason for 'expired' recovery points is the absence of the permissions necessary for deletion. During the lifecycle run, if AWS Backup finds that the original AWS Identity and Access Management (IAM) role that created the recovery point was deleted, or if that IAM role does not have permissions to delete the backup / recovery point, then AWS Backup will fail the deletion and move the recovery point to the 'expired' state. Expired recovery points can only be manually deleted using the AWS management console.

Use the detailed diagnosis of this measure to know which recovery points are being deleted.