Passer au contenu

Pourquoi ma copie intercompte échoue-t-elle dans AWS Backup ?

Lecture de 6 minute(s)
0

Je souhaite résoudre les problèmes liés à l'échec de ma tâche de copie intercompte dans AWS Backup.

Brève description

Pour résoudre les problèmes liés à l'échec de votre tâche de copie sur l’ensemble des comptes AWS, vérifiez les configurations suivantes :

  • Vérifiez que vos comptes source et de destination appartiennent à la même organisation dans AWS Organizations.
  • Assurez-vous que le type de ressource prend en charge la copie intercompte dans les régions AWS spécifiées.
  • Examinez les critères de chiffrement pour la sauvegarde de votre compte source.
  • Vérifiez que la stratégie de clé source d'AWS Key Management Service (AWS KMS) intègre le compte de destination.
  • Vérifiez que la stratégie d'accès au coffre-fort de destination intègre le compte source.
  • Assurez-vous d'avoir correctement configuré la stratégie de balisage de l'organisation.

Résolution

Important : Lorsque vous copiez une sauvegarde dans une nouvelle région ou sur plusieurs comptes pour la première fois, AWS Backup copie la sauvegarde dans son intégralité. Si un service prend en charge les sauvegardes incrémentielles, les copies suivantes de la sauvegarde dans la même région ou le même compte sont incrémentielles. AWS Backup chiffre votre copie à l'aide de la clé gérée par le client de votre coffre-fort de destination. La copie intercompte nécessite une autorisation et des autorisations appropriées entre les comptes source et de destination.

Pour plus d'informations, consultez la section Chiffrement des copies d'une sauvegarde vers un autre compte ou une autre région AWS.

Vérifier les comptes membres de votre organisation

Si vos comptes source et de destination ne font pas partie de la même organisation, le message d'erreur suivant s'affiche :

"Copy job failed. Both source and destination account must be a member of the same organization."

Pour résoudre ce problème, migrez l'un de vos comptes vers la même organisation que l'autre compte.

Vérifier si le type de ressource prend en charge l'action de copie

Assurez-vous que le service AWS pour vos ressources prend en charge les sauvegardes intercomptes et interégionales. Pour obtenir la liste des fonctionnalités prises en charge par les services AWS pour AWS Backup, consultez la section Disponibilité des fonctionnalités par ressource. Pour obtenir la liste des fonctionnalités disponibles par région, consultez la section Disponibilité des fonctionnalités par région AWS.

Si votre ressource ne prend pas en charge une action de copie qui effectue à la fois des sauvegardes de copie intercomptes et interrégionales, vous recevez un message d'erreur similaire au suivant :

"Copy job from us-west-2 to us-east-1 cannot be initiated for RDS resources. Feature is not supported for provided resource type."

Les services suivants ne prennent pas en charge l'action de copie pour effectuer à la fois des sauvegardes intercomptes et interrégionales :

  • Amazon Relational Database Service (Amazon RDS)
  • Amazon Aurora
  • Amazon DocumentDB (compatible avec MongoDB)
  • Amazon Neptune

Pour les services précédents, vous devez effectuer une sauvegarde intercompte et interrégionale. Pour Amazon DynamoDB, vous devez activer DynamoDB avec les fonctionnalités avancées d'AWS Backup pour effectuer des sauvegardes intercomptes.

Examiner les critères de chiffrement

Si votre tâche de sauvegarde intercompte échoue en raison de problèmes de chiffrement, l'un des messages d'erreur suivants s'affiche :

"Copy job failed because the destination Backup vault is encrypted with the default Backup service managed key. The contents of this vault cannot be copied. Only the contents of a Backup vault encrypted by a customer master key (CMK) may be copied."

-ou-

"Snapshots encrypted with the AWS Managed CMK can't be shared. Specify another snapshot. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameter; Request ID: ; Proxy: null)"

Pour résoudre ces problèmes, procédez comme suit :

  1. Créez une nouvelle sauvegarde de la ressource.
  2. Restaurez la ressource et sélectionnez une clé gérée par le client AWS KMS.
  3. Créez une nouvelle sauvegarde de la ressource restaurée.
  4. Effectuez la copie intercompte.

Pour les ressources non entièrement gérées par AWS Backup, les sauvegardes utilisent la même clé AWS KMS que la ressource source. Pour les ressources entièrement gérées, les sauvegardes utilisent la clé de chiffrement du coffre-fort de sauvegarde.

Pour plus d'informations, consultez la section Chiffrement des sauvegardes dans AWS Backup.

Remarque : AWS Backup ne prend pas en charge la copie intercompte avec des clés gérées par AWS pour les ressources non entièrement gérées par AWS Backup.

Vérifier la stratégie de clé KMS source

Si la stratégie de clé AWS KMS du compte source n'autorise pas le compte de destination, vous recevez l'un des messages d'erreur suivants :

"The source snapshot KMS key does not exist, is not enabled or you do not have permissions to access it"

-ou-

"AMI snapshot copy failed with error: Given key ID is not accessible. You must have DescribeKey permissions on the default CMK."

Pour résoudre ces problèmes, ajoutez des autorisations pour le compte de destination à la politique clé AWS KMS source.

Utilisez l'exemple de politique suivant :

{  "Version": "2012-10-17",
  "Id": "cab-kms-key",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SourceAccountID :root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::SourceAccountID :root",
          "arn:aws:iam::DestinationAccountID:root"
        ]
      },
      "Action": [
        "kms:DescribeKey",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::SourceAccountID:root",
          "arn:aws:iam::DestinationAccountID:root"
        ]
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

Remarque : Remplacez SourceAccountID par l’ID de votre compte source et DestinationAccountID par l'ID de votre compte de destination.

Vérifier la stratégie d'accès au coffre-fort de destination

Si vous n'avez pas partagé le coffre-fort AWS Backup de destination avec le compte source, le message d'erreur suivant s'affiche :

"Access Denied trying to call AWS Backup service"

Pour résoudre ce problème, ajoutez des autorisations pour votre compte source à la politique d'accès au coffre-fort de destination.

Utilisez l'exemple de politique suivant :

{  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SourceAccountID:root"
      },
      "Action": "backup:CopyIntoBackupVault",
      "Resource": "*"
    }
  ]
}

Remarque : Remplacez SourceAccountID par l'ID de votre compte source.

Vérifier la stratégie de balisage de votre organisation

AWS Backup copie les identifications des ressources vers les points de restauration. Par exemple, lorsque vous sauvegardez un volume Amazon Elastic Block Store (Amazon EBS), AWS Backup copie les identifications dans l'instantané. Pour plus d'informations, consultez la section Copier des identifications lors d'une restauration.

Si votre tâche de sauvegarde intercompte échoue en raison d'une stratégie de balisage incorrecte, l'un des messages d'erreur suivants s'affiche :

"We are unable to copy resource tags to your backup because of the Internal Failure"

-ou-

"The tag policy does not allow the specified value for the following tag key: 'xyz'"

Pour résoudre ces problèmes, procédez comme suit :

AWS OFFICIELA mis à jour il y a 4 mois