Sauvegarde et Point-in-Time Recovery DynamoDB : le guide complet

DynamoDB protège tes données de deux façons. Les sauvegardes à la demande sont des instantanés complets que tu prends et conserves indéfiniment. La restauration à un instant dans le passé (PITR) est une sauvegarde continue et automatique qui te permet de restaurer la table à n'importe quelle seconde à l'intérieur d'une fenêtre glissante. Les deux restaurent vers une nouvelle table — ce sont des outils de récupération, pas un bouton d'annulation.

Pour le journal d'audit, c'est non négociable. C'est un enregistrement de conformité immuable ; une mauvaise migration qui réécrit des événements, ou une suppression en masse accidentelle, doit être récupérable jusqu'à l'instant précédant l'erreur.

Comment fonctionnent la sauvegarde et la restauration à un instant dans le passé de DynamoDB ?

DynamoDB propose deux types de sauvegarde. La restauration à un instant dans le passé (PITR) prend des sauvegardes automatiques continues, te permettant de restaurer à n'importe quelle seconde dans une fenêtre configurable de 1 à 35 jours. Les sauvegardes à la demande sont des instantanés complets manuels conservés indéfiniment. Les deux restaurent vers une nouvelle table, jamais par-dessus l'originale, ce qui en fait des outils de récupération plutôt qu'une annulation sur place.

• PITR = sauvegarde continue, restauration à n'importe quelle seconde dans une fenêtre configurable de 1 à 35 jours (c'était autrefois un 35 fixe).
• Sauvegardes à la demande = instantanés complets manuels conservés aussi longtemps que tu veux, indépendamment de la fenêtre PITR.
• Les restaurations créent une nouvelle table. Tu restaures vers un nouveau nom, puis tu bascules — l'originale reste intacte.
• La PITR est tarifée sur la taille de la table, pas sur le nombre de points de restauration — estime-la avec le calculateur de tarifs DynamoDB.

Le problème : une erreur que tu ne peux pas annuler sur place

DynamoDB n'a aucun journal de transactions que tu peux dérouler en arrière et aucun « annuler » sur une écriture. Si un script de migration réécrit le champ action de chaque événement, ou si quelqu'un lance une suppression plus large que prévu, la table est simplement dans le mauvais état. Sans sauvegardes, les données sont perdues.

Pour un journal d'audit — dont toute la valeur est d'être un enregistrement digne de confiance — « on ne peut pas récupérer les événements de mardi dernier » est un échec de conformité, pas juste un désagrément.

Comment fonctionnent la sauvegarde et la PITR

La restauration à un instant dans le passé, une fois activée, prend des sauvegardes automatiques continues. Selon les docs AWS, la PITR te donne des sauvegardes continues entièrement gérées des données de table avec une granularité de restauration à la seconde. La fenêtre est configurable de 1 à 35 jours via RecoveryPeriodInDays, et tu peux restaurer à n'importe quelle seconde à l'intérieur — jusqu'à environ cinq minutes derrière le temps réel (LatestRestorableDateTime) — y compris vers une région différente.

Une limite importante : diminuer la période de récupération réduit immédiatement le point de restauration le plus ancien, et désactiver puis réactiver la PITR réinitialise l'heure de début récupérable — tu perds l'historique continu antérieur.

La PITR conditionne aussi l'export vers S3 géré : l'export lit les mêmes sauvegardes continues, donc avec la PITR désactivée, ExportTableToPointInTime échoue avec PointInTimeRecoveryUnavailableException.

Les sauvegardes à la demande sont distinctes : des instantanés manuels de table complète que tu crées explicitement et conserves indéfiniment, utiles pour un point de contrôle avant migration ou une archive de conformité à long terme au-delà de la fenêtre PITR de 35 jours. La demande est traitée instantanément et la sauvegarde devient restaurable en quelques minutes, ne consomme aucun débit de la table, et il n'y a aucune limite au nombre que tu en conserves. Une réserve honnête tirée des docs : les sauvegardes à la demande ne garantissent pas la cohérence causale entre les éléments — l'écart entre les mises à jour est "usually much less than a second", mais une sauvegarde prise en plein pic d'écritures n'est pas un instant unique figé.

Ce qu'une restauration ne rétablit pas

Une restauration recrée les données de la table et ses index — pas son câblage opérationnel. D'après les docs AWS, tu dois reconfigurer manuellement sur la table restaurée : les politiques d'auto-scaling, les politiques IAM, les métriques et alarmes CloudWatch, les tags, les paramètres de stream, le TTL, la protection contre la suppression, et la PITR elle-même. Restaurer depuis une sauvegarde en oubliant de réactiver la PITR, c'est ainsi que le prochain incident devient irrécupérable.

Au moment de la restauration, tu peux délibérément changer certains paramètres — mode de facturation, capacité provisionnée, clés de chiffrement — et tu peux exclure tout ou partie des index secondaires, ce qui rend la restauration plus rapide et moins chère si tu peux les reconstruire ensuite. Une restauration peut aussi cibler une région différente, et elle n'écrase jamais une table existante.

Sauvegardes planifiées avec AWS Backup

Les sauvegardes à la demande natives de DynamoDB n'ont aucun planificateur. Pour des sauvegardes récurrentes avec rétention, DynamoDB s'intègre nativement avec AWS Backup (docs AWS) : les plans de sauvegarde te donnent des sauvegardes planifiées avec des règles de cycle de vie (y compris le passage en stockage froid), des copies inter-comptes et inter-régions automatiques pour le PRA, une clé KMS indépendante via le coffre de sauvegarde, et Vault Lock pour une posture de conformité WORM que personne ne peut discrètement supprimer. Deux pièges opérationnels : AWS Backup demande une activation explicite par compte et par région, et les sauvegardes qu'il crée (type AWS_BACKUP) ne peuvent pas être supprimées depuis la console DynamoDB — gère-les dans AWS Backup.

Les deux restaurent vers une nouvelle table, pas par-dessus l'existante :

Un exemple travaillé : récupérer d'une mauvaise migration

Une migration censée ajouter un attribut expiresAt a plutôt écrasé action sur chaque événement avec une chaîne vide. La PITR est activée avec une fenêtre de 35 jours, donc tu restaures à la seconde précédant l'exécution de la migration :

La table corrompue reste intacte pendant que tu vérifies la restauration — tu compares les événements restaurés aux événements en direct, tu confirmes que les valeurs action sont revenues, puis tu repointes l'appli. Rien n'est détruit dans la récupération elle-même.

Si la perte n'était qu'une poignée d'éléments plutôt qu'une corruption de table entière, tu pourrais plutôt inspecter les données en direct et la copie restaurée et copier uniquement les lignes affectées — voir copier une table DynamoDB.

Fais-le dans DynoTable

Une restauration ne vaut que la vérification que tu en fais. Après avoir restauré vers audit-log-restored, tu dois réellement regarder les événements récupérés et confirmer qu'ils correspondent à ce qu'ils auraient dû être avant l'erreur.

DynoTable se connecte à la table restaurée comme à n'importe quelle autre, donc tu peux interroger les événements du tenant affecté, confirmer que les valeurs action sont correctes, et comparer à la table en direct avant de basculer — transformant une restauration d'un acte de foi en une récupération vérifiée.

Tu peux aussi exporter les événements récupérés pour un enregistrement de conformité hors ligne — voir exporter DynamoDB en CSV.

Pièges et étapes suivantes

• Active la PITR avant d'en avoir besoin. Elle ne protège qu'à partir du moment où elle est activée — il n'y a pas de récupération rétroactive. Active-la pour toute table dont tu ne peux pas te permettre de perdre les données.
• Désactiver la PITR réinitialise la fenêtre. La couper puis la rallumer efface l'historique continu ; l'heure de début récupérable repart à partir de la réactivation.
• Les restaurations ne sont ni instantanées ni gratuites. Une restauration provisionne toute une nouvelle table et prend un temps proportionnel à la taille ; prévois la durée et la table supplémentaire.
• 35 jours n'est pas de l'archivage. Pour une rétention au-delà de la fenêtre PITR, prends des sauvegardes à la demande ou exporte vers S3 — la PITR est une fenêtre de récupération, pas un stockage à long terme.

Cela boucle la boucle des opérations du journal d'audit : les transactions pour la cohérence, les Streams pour la réaction, le TTL pour l'expiration, le bon mode de capacité pour le coût, les tables globales pour la résilience régionale, et la PITR pour la récupération des données. Reviens à la vue d'ensemble Opérations & Coût pour voir comment ils s'articulent.

Télécharge DynoTable pour te connecter à une table restaurée et vérifier ta récupération avant de lui faire confiance.