Sauvegarde et restauration à un instant donné (PITR) dans DynamoDB
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 donné (PITR) est une sauvegarde continue et automatique qui te permet de restaurer la table à n'importe quelle seconde dans une fenêtre glissante. Les deux restaurent vers une table nouvelle — 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 migration ratée qui réécrit des événements, ou une suppression en masse accidentelle, doit pouvoir être récupérée jusqu'à l'instant précédant l'erreur.
Comment fonctionnent la sauvegarde et la restauration à un instant donné dans DynamoDB ?
DynamoDB propose deux types de sauvegarde. La restauration à un instant donné (PITR) prend des sauvegardes continues automatiques, ce qui te permet 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 sont donc des outils de récupération plutôt qu'un bouton d'annulation sur place.
- PITR = sauvegarde continue, restauration à n'importe quelle seconde dans une fenêtre configurable de 1 à 35 jours (c'était auparavant 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 sous un nouveau nom, puis tu bascules — l'originale reste intacte.
- Le PITR est facturé sur la taille de la table, pas sur le nombre de points de restauration — estime-le 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 pourrais annuler et aucun « undo »
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 un mauvais état. Sans sauvegardes, les données sont perdues.
Pour un journal d'audit — dont toute la valeur tient à ê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 le PITR
La restauration à un instant donné, une fois activée, prend des sauvegardes
continues automatiques. D'après la
documentation AWS,
le PITR « fournit des sauvegardes continues automatiques entièrement gérées des
données de la table, avec jusqu'à 35 jours de points de restauration à la granularité
de la seconde ». La fenêtre est configurable de 1 à 35 jours via
RecoveryPeriodInDays, et tu peux restaurer à n'importe quelle seconde à l'intérieur
— y compris vers une autre région.
Un point limite important : réduire la période de restauration repousse immédiatement le point de restauration le plus ancien, et désactiver puis réactiver le PITR remet à zéro l'instant de départ récupérable — tu perds l'historique continu précédent.
Les sauvegardes à la demande sont distinctes : des instantanés manuels et complets de la table 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.
Les deux restaurent vers une nouvelle table, pas par-dessus l'existante :
Un exemple concret : récupérer après une mauvaise migration
Une migration censée ajouter un attribut expiresAt a au lieu de cela écrasé action
sur chaque événement avec une chaîne vide. Le PITR est activé avec une fenêtre de
35 jours, donc tu restaures à la seconde avant que la migration ne s'exécute :
| étape | résultat |
|---|---|
| restaurer PITR à 09:59:00 | nouvelle table audit-log-restored avec les actions correctes |
| comparer au live | confirmer que seules les lignes de la migration diffèrent |
| basculer l'app sur restored | originale laissée intacte pour analyse |
La table corrompue reste intacte pendant que tu vérifies la restauration — tu compares
les événements restaurés aux événements en live, tu confirmes que les valeurs action
sont de retour, puis tu repointes l'app. Rien n'est détruit dans la récupération
elle-même.
Si la perte ne concernait qu'une poignée d'items plutôt qu'une corruption de toute la table, tu pourrais à la place inspecter les données en live et la copie restaurée, et ne copier que les lignes affectées — voir copier une table DynamoDB.
Fais-le dans DynoTable
Une restauration ne vaut que par 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 live 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 le PITR avant d'en avoir besoin. Il ne protège qu'à partir du moment où il est activé — pas de récupération rétroactive. Active-le pour toute table dont tu ne peux pas te permettre de perdre les données.
- Désactiver le PITR remet la fenêtre à zéro. Le couper puis le réactiver efface l'historique continu ; l'instant de départ récupérable repart depuis la réactivation.
- Les restaurations ne sont ni instantanées ni gratuites. Une restauration provisionne une toute nouvelle table et prend un temps proportionnel à la taille ; prévois la durée et la table supplémentaire.
- 35 jours, ce 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 — le PITR est une fenêtre de récupération, pas du stockage à long terme.
Cela boucle le cycle des opérations du journal d'audit : transactions pour la cohérence, Streams pour la réaction, TTL pour l'expiration, le bon mode de capacité pour le coût, les Global Tables pour la résilience régionale, et le PITR pour la récupération des données. Reviens à la vue d'ensemble Opérations & coût pour voir comment tout s'articule.
Télécharge DynoTable pour te connecter à une table restaurée et vérifier ta récupération avant de lui faire confiance.