BackupInUseException
En bref — Une opération de plan de contrôle de sauvegarde conflictuelle est encore en cours sur cette table : la sauvegarde est en train d'être créée, supprimée ou restaurée en ce moment. Ces opérations se sérialisent — attends que celle en cours se termine (vérifie BackupStatus via DescribeBackup), puis réessaie la tienne.
Ce que ça signifie
BackupInUseException: There is another ongoing conflicting backup control
plane operation on the table. The backup is either being created, deleted
or restored to a table.Les opérations de sauvegarde à la demande (CreateBackup, DeleteBackup, RestoreTableFromBackup) sont des appels de plan de contrôle, et DynamoDB rejette celles qui entreraient en conflit avec une opération déjà en cours sur la même sauvegarde ou table. C'est une erreur d'état transitoire, pas un problème de permissions ou de données.
Pourquoi ça arrive
- Supprimer une sauvegarde encore en cours de création — le
CreateBackupn'a pas encore atteintAVAILABLE. - Supprimer une sauvegarde pendant qu'une restauration à partir de celle-ci est en cours — la restauration retient la sauvegarde jusqu'à la fin de la création de la nouvelle table.
- Automatisation qui se chevauche — un script de nettoyage et un planificateur de sauvegarde qui se font la course, ou une boucle de réessai qui déclenche deux fois
CreateBackupsur la même table. - Dépasser la limite de débit —
DeleteBackupaccepte au plus 10 appels par seconde ; balayer de nombreuses sauvegardes dans une boucle serrée déclenche conflits et throttling à la fois.
Comment corriger
Vérifie ce qui est en cours, puis attends :
aws dynamodb describe-backup --backup-arn arn:aws:dynamodb:...:table/orders/backup/01234... # BackupStatus: CREATING | AVAILABLE | DELETEDRéessaie ton opération une fois le statut stabilisé (
AVAILABLEpour une création terminée ; une table en restauration atteintACTIVEviadescribe-table).Réessaie avec un backoff plutôt que d'échouer brutalement — les opérations de sauvegarde prennent de quelques secondes à quelques minutes ; une simple boucle attendre-et-réessayer autour de l'appel absorbe la sérialisation.
Sérialise ton automatisation — un seul propriétaire par table pour les opérations de cycle de vie des sauvegardes ; mets les suppressions en file derrière les créations plutôt que de faire tourner les deux sur un cron qui peut se chevaucher.
Modère les suppressions en masse — reste sous 10 appels
DeleteBackup/seconde et traite cette exception comme le signal de ralentir.
Les sauvegardes protègent les données que tu peux le moins te permettre de perdre — parcours ce qu'il y a réellement dans une table avant d'élaguer ses sauvegardes avec l'application de bureau DynoTable, et estime le trafic de lecture des restaurations avec le calculateur de tarification DynamoDB.
Erreurs liées
- BackupNotFoundException — l'ARN ne correspond à aucune sauvegarde.
- Table already exists — restauration vers un nom déjà pris.
- LimitExceededException — trop d'opérations de plan de contrôle simultanées.
- Apprends : Backups & point-in-time recovery
Références
- DeleteBackup — Amazon DynamoDB API Reference
- RestoreTableFromBackup — Amazon DynamoDB API Reference
- DescribeBackup — Amazon DynamoDB API Reference
- Restoring a DynamoDB table from a backup — Amazon DynamoDB Developer Guide
Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.