How do I troubleshoot failed restore testing plans in AWS Backup?

Resolution

AWS Backup restore testing plans might fail for the following reasons:

• You have no available default subnets in your Amazon Virtual Private Cloud (Amazon VPC).
• You don't have the necessary AWS Identity and Access Management (IAM) permissions.
• If you encrypted your backup, then you might not have AWS Key Management Service (AWS KMS) key access.

You have no available subnets in your VPC

If the default Amazon VPC in your test AWS Region doesn't have available subnets, then you receive the following error message:

"No default subnet detected in VPC. Please contact AWS Support to recreate default Subnets."

To resolve this issue, take one of the following actions:

• Create a default subnet in your Amazon VPC.
• When you configure your Amazon Elastic Compute Cloud (Amazon EC2) instance, For Advanced details, specify the subnetId parameter for the subnet that you want your EC2 instance to launch.
• Use the Amazon Relational Database Service (Amazon RDS) console to create a DB subnet group that defines the subnets that your DB instance can use.

If you delete a default Amazon VPC or subnet and don't override the metadata, then the restore operation fails. For more information about metadata overrides for restore operations, see Restore testing inferred metadata.

You don't have the necessary IAM permissions

Note: To test your restores, make sure that you attached the AWSServiceRoleForBackupRestoreTesting policy to your IAM service-linked role. If you don't have permission to create or edit a service-linked role, then see Service-linked role permissions.

If your IAM role doesn't have the correct trust relationship to allow AWS Backup to assume the role, then you receive the following error message:

"IAM Role cannot be assumed by AWS Backup."

To resolve this issue, update the role trust policy to include the following statement:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "backup.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Note: The preceding policy statement includes backup.amazonaws.com as the service. You can also update your restore testing plan to use the AWSBackupDefaultServiceRole default service role for AWS Backup.

You don't have AWS KMS key access

If the restore role can't access the AWS KMS keys that encrypt backups, then you receive one of the following error messages:

• "Access denied to KMS key."
• "The specified AWS KMS key ARN does not exist, is not enabled or you do not have permissions to access it."

To resolve this issue, complete the following steps:

1. Add the following AWS KMS permissions to your IAM role's policy:

   {
       "Effect": "Allow",
       "Action": [
         "kms:DescribeKey",
         "kms:GenerateDataKey",
         "kms:Decrypt"
       ],
       "Resource": [
        "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
   }

   Note: Replace the example Amazon Resource Name (ARN) with your AWS KMS key's ARN.

2. Update your AWS KMS key policy to allow the restore role access:

   {
     "Effect": "Allow",
     "Principal": {
       "AWS": "arn:aws:iam::ACCOUNT-ID:role/RESTORE-ROLE-NAME"
     },
     "Action": [
       "kms:Decrypt",
       "kms:GenerateDataKey",
       "kms:CreateGrant"
     ],
     "Resource": "*"
   }

   Note: Replace RESTORE-ROLE-NAME with the IAM role that you use to restore your backups.

Related information

How to restore

Restore testing

Restore testing validation

Troubleshooting restoring resources