DynamoDB BackupNotFoundException

En bref — DynamoDB n'a aucune sauvegarde correspondant au BackupArn que tu as fourni. Presque toujours un ARN incorrect ou mal formé, une sauvegarde qui a été supprimée ou a expiré, ou un client pointé vers la mauvaise région/mauvais compte. Liste les sauvegardes de la table et copie l'ARN exact.

Ce que ça signifie

BackupNotFoundException: Backup not found for the given BackupARN.

Les appels de restauration et de description (RestoreTableFromBackup, DescribeBackup, DeleteBackup) adressent une sauvegarde par son ARN. Ce HTTP 400 signifie qu'aucune sauvegarde n'existe à cet ARN dans la région + le compte auxquels tes identifiants se résolvent. C'est côté client et non réessayable tant que l'ARN n'est pas correct.

Pourquoi ça arrive

ARN incorrect ou mal formé — une faute de frappe, un ARN tronqué, ou un ARN construit à la main plutôt que copié depuis list-backups.
La sauvegarde a été supprimée ou a expiré — quelqu'un a retiré la sauvegarde à la demande, une règle de cycle de vie AWS Backup l'a fait expirer, ou c'était une sauvegarde SYSTEM (créée automatiquement quand une table avec PITR activé est supprimée), qui expire 35 jours après sa création.
Mauvaise région — list-backups/describe-backup sont régionaux ; la sauvegarde vit dans la région où elle a été créée (la région intégrée dans son ARN), donc un client pointé ailleurs ne peut pas la voir.
Mauvais compte — les identifiants se résolvent vers un compte AWS différent de celui qui possède la sauvegarde.
Point de récupération géré par AWS Backup — les sauvegardes planifiées via AWS Backup sont stockées comme points de récupération dans un coffre AWS Backup, où des règles de cycle de vie peuvent les transférer ou les supprimer ; consulte la console AWS Backup si une sauvegarde n'est pas là où tu l'attends.

Comment le corriger

Liste les sauvegardes de la table et récupère l'ARN réel :
```
aws dynamodb list-backups --table-name <Table> --region <r>
```
Vérifie qu'elle existe et est disponible :
```
aws dynamodb describe-backup --backup-arn <arn> --region <r>
```
BackupStatus devrait être AVAILABLE — une sauvegarde en cours de création/suppression/restauration rejette les appels conflictuels avec BackupInUseException à la place.
Fixe la région sur celle de l'ARN de la sauvegarde (là où la sauvegarde a été créée).
Confirme le compte avec aws sts get-caller-identity.
Sauvegarde prise par un plan AWS Backup ? Recherche-la dans la console AWS Backup (les points de récupération de son coffre) — les règles de cycle de vie y peuvent transférer ou supprimer des sauvegardes selon un planning.

Connecte-toi depuis DynoTable

DynoTable est un atelier de tables, pas une console de sauvegarde — sers-t'en pour confirmer que la table en direct existe bien dans la région où tu comptes restaurer, avant d'appeler RestoreTableFromBackup. Ouvre le profil de la région cible (⌘P), ⌘K → ouvre la table par son nom, et vérifie le compte avec le statut des identifiants sur la pastille de profil.

Si la restauration échoue avec BackupNotFoundException, l'ARN est faux ou périmé ; corrige ça dans les API AWS Backup / sauvegardes DynamoDB, puis reviens dans DynoTable pour inspecter le schéma et les éléments de la table restaurée. Le calculateur de taille d'élément aide à vérifier qu'une forme d'élément restaurée tient encore dans ton plan de capacité.

Sources

DescribeBackup — Amazon DynamoDB API Reference (vérifié le 2026-07-13)
Restoring a DynamoDB table from a backup (vérifié le 2026-07-13)

Erreurs liées

BackupInUseException — la sauvegarde existe mais une opération de sauvegarde conflictuelle est encore en cours.
ResourceNotFoundException — la table elle-même est introuvable dans la région/le compte.
Table already exists — le nom de la table cible de la restauration est déjà pris.
Apprends : Backups & point-in-time recovery

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.