Restauration RDS à un instant précis : ce qu'elle peut rembobiner

La restauration RDS à un instant précis (PITR) peut reconstruire votre base telle qu’elle existait à n’importe quelle seconde de votre fenêtre de rétention — typiquement jusqu’à environ cinq minutes avant maintenant. Elle ne peut pas restaurer sur place, ne peut pas rembobiner une seule table par elle-même, ne peut pas remonter au-delà de la fenêtre de rétention, et ne peut pas vous sauver si les sauvegardes ont été supprimées avec l’instance. Connaître ces quatre limites avant le mauvais jour fait la différence entre une récupération de 45 minutes et un après-midi qui marque une carrière.

Ce qui se passe

Quand BackupRetentionPeriod est d’au moins 1 jour, RDS expédie continuellement les journaux de transactions vers S3, environ toutes les cinq minutes, en plus du snapshot automatisé quotidien. Un PITR prend le snapshot le plus proche avant votre heure cible et rejoue les journaux jusqu’à la seconde exacte demandée. Deux horodatages définissent votre vraie fenêtre : EarliestRestorableTime (borné par la rétention, 1–35 jours) et LatestRestorableTime (habituellement maintenant moins quelques minutes, parce que le dernier lot de journaux est encore en transit).

Ce que le PITR vous donne : la récupération d’une table droppée, d’une mauvaise migration, d’un UPDATE sans WHERE, ou d’une corruption applicative — tant que vous savez à peu près quand c’est arrivé et que c’est arrivé dans la fenêtre.

Ce que le PITR ne vous donne pas :

Un rembobinage sur place. Comme une restauration de snapshot, le PITR crée toujours une nouvelle instance. Votre instance de production continue d’exister, et toutes les surprises de configuration de la nouvelle instance — parameter group par défaut, security group par défaut, nouvel endpoint — s’appliquent ici aussi.
La restauration au niveau table. Vous restaurez toute l’instance à l’heure cible, puis vous copiez vous-même la table dont vous avez besoin vers la production.
Quoi que ce soit avant la fenêtre. Une rétention de 7 jours signifie que le jour 8 est hors de portée du PITR; seuls les snapshots manuels remontent plus loin.
La récupération d’une instance supprimée, sauf si les sauvegardes ont survécu. Supprimer une instance supprime normalement ses sauvegardes automatisées après le délai de grâce, à moins que les sauvegardes automatisées retenues soient conservées ou que vous ayez pris un snapshot final. Si les deux ont été sautés, le PITR n’a rien à rejouer.
Les externalités non répliquées. Les données que votre application a écrites vers S3, des files d’attente ou des tiers après le point de restauration restent écrites; le PITR ne rembobine que la base.

Les mécanismes et notes par moteur sont dans la documentation de sauvegarde RDS sur https://docs.aws.amazon.com/rds/. Comment concevoir la stratégie de rétention et de snapshots autour du PITR — fenêtres, copies inter-régions, et l’exercice trimestriel — est couvert dans le runbook stratégie PITR + snapshots RDS.

Quoi vérifier en premier

Votre fenêtre réelle — EarliestRestorableTime et LatestRestorableTime, pas ce que vous supposez de la rétention.
L’horodatage du dommage — depuis les journaux applicatifs, CloudTrail, ou les journaux d’audit. Restaurez juste avant, avec une minute de marge.
Si l’instance existe encore — instance vivante : PITR normal; supprimée : vérifiez vite les sauvegardes automatisées retenues.
Les noms de configuration de production — parameter group, security groups, subnet group, prêts à passer explicitement.
La discipline de fuseau horaire — les heures de restauration sont en UTC; une erreur de fuseau restaure cinq heures des mauvaises données.

Comment vérifier

aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].[BackupRetentionPeriod,LatestRestorableTime]'

aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].EarliestRestorableTime'

Pour une instance supprimée, vérifiez si des sauvegardes automatisées retenues existent encore :

aws rds describe-db-instance-automated-backups \
  --query 'DBInstanceAutomatedBackups[].[DBInstanceIdentifier,RestoreWindow,Status]'

Dans la console, les mêmes chiffres vivent sous RDS > Automated backups, et sur une instance vivante sous RDS > Databases > (instance) > Maintenance & backups. Cernez l’heure du dommage avec CloudTrail si la cause était une action d’API, ou avec le journal d’audit/général du moteur si c’était du SQL.

La marche à suivre

Gelez le rayon d’impact. Si de mauvaises écritures continuent, arrêtez la tâche fautive ou révoquez l’identifiant d’abord — restaurer pendant que le dommage continue ne fait que déplacer la cible.
Fixez l’heure cible en UTC et écrivez-la. Un seul horodatage faisant autorité, convenu dans le canal d’incident, une minute avant la première mauvaise écriture.

Restaurez vers une nouvelle instance avec une configuration explicite :

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-db \
  --target-db-instance-identifier prod-db-pitr \
  --restore-time 2026-07-03T18:31:00Z \
  --db-subnet-group-name prod-db-subnets \
  --vpc-security-group-ids sg-0abc123def456 \
  --db-parameter-group-name prod-pg16-params \
  --no-publicly-accessible

Utilisez --use-latest-restorable-time au lieu de --restore-time quand l’instance est morte et que vous voulez simplement tout ce qui est récupérable.

Validez contre le dommage. Confirmez que la table droppée existe, que les lignes corrompues sont propres, et que les dernières transactions légitimes avant l’heure cible sont présentes.
Choisissez bascule complète ou copie chirurgicale. Base entière empoisonnée : basculez les applications vers l’instance restaurée. Une table ou quelques lignes : exportez depuis la copie restaurée (pg_dump --table, mysqldump avec une liste de tables) et chargez en production, ce qui évite de perdre les bonnes écritures survenues après l’incident.
Réconciliez l’écart. Les écritures entre le point de restauration et la bascule ont disparu de la base — récupérez-les des journaux applicatifs ou des files d’attente quand c’est possible, et dites honnêtement à l’entreprise quel est l’écart.
Nettoyez à une date fixée. L’instance restaurée se facture comme n’importe quelle autre; prenez-en un snapshot, planifiez sa suppression, et fermez la boucle.

Quand c’est la mauvaise approche

Si l’incident était une panne matérielle plutôt que de mauvaises données, le failover Multi-AZ l’a déjà géré — le PITR ne ferait que vous perdre les dernières minutes pour rien. Si le dommage précède votre fenêtre de rétention, arrêtez et regardez plutôt les snapshots manuels ou les données exportées. Et si vous avez besoin du même état récent de façon répétée pour des tests plutôt que pour une récupération, les clones rapides Aurora ou une restauration de snapshot sont moins chers et plus rapides que des PITR répétés.

Erreurs courantes

Restaurer à l’heure où vous avez remarqué le problème au lieu de l’heure où il a commencé — des heures de corruption reviennent avec les données.
Faire une bascule complète pour un incident d’une seule table, jetant toutes les bonnes écritures depuis le point de restauration.
Perdre la restauration à cause du fuseau horaire — --restore-time est en UTC, votre canal d’incident probablement pas.
Supposer que le PITR couvre une instance supprimée alors que personne n’a activé les sauvegardes automatisées retenues et que personne n’a pris de snapshot final.

Prévention

Fixez la rétention pour couvrir un délai de détection réaliste — 7 jours minimum en production; 1 jour signifie « remarquez-le aujourd’hui ou perdez-le ».
Mettez une alarme si LatestRestorableTime prend plus de 10–15 minutes de retard sur maintenant; c’est votre expédition de journaux qui traîne.
Activez la protection contre la suppression et les sauvegardes automatisées retenues sur les instances de production.
Faites un exercice PITR trimestriel et chronométrez-le — la durée de restauration varie avec la taille de la base et la distance de rejeu des journaux, et l’entreprise mérite un vrai chiffre de RTO.

Le PITR est la fonctionnalité qui transforme « quelqu’un a droppé la table à 14 h 30 » d’un désastre en une procédure — mais seulement dans sa fenêtre, seulement vers une nouvelle instance, et seulement si les sauvegardes ont survécu à l’erreur. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.