Stratégie PITR + snapshots RDS / Aurora — le runbook que vous répétez vraiment

Le client dit « on a des snapshots, on est couverts ». Les snapshots tournent toutes les nuits, sont retenus 7 jours et restent dans la région source. Le client n’a jamais restauré depuis un. Trois mois plus tard, le mauvais DBA a droppé la mauvaise table à 14:30 un jeudi et l’application est partie de travers. Le snapshot de 02:00 a 12 heures, l’équipe n’a pas fait de drill de restauration, et le propriétaire de l’application a besoin des données restaurées jusqu’à la dernière heure. PITR (Point-In-Time Recovery) est la fonctionnalité qui couvre ce trou, et la stratégie autour — rétention, inter-régions, drills de restauration — est la différence entre « on est couverts » et « on est vraiment couverts ».

Ce qui se passe

RDS et Aurora livrent quatre mécanismes de sauvegarde qui se chevauchent. Chacun résout un scénario de récupération différent.

Snapshots automatisés. Snapshots quotidiens au niveau stockage, conservés pour la BackupRetentionPeriod que vous fixez (1–35 jours). Restaurés comme une nouvelle base, au moment du snapshot, dans la région source.

PITR (Point-In-Time Recovery). Activé par défaut chaque fois que BackupRetentionPeriod vaut au moins 1. RDS conserve les journaux de transactions en continu et permet de restaurer à n’importe quelle seconde dans la fenêtre de rétention. La restauration crée une nouvelle instance — vous ne pouvez pas restaurer in-place. Le temps de restauration dépend de la taille du cluster et de la distance au snapshot le plus proche.

Snapshots manuels. Snapshots à la demande que vous conservez jusqu’à suppression explicite. Ils survivent à la suppression de l’instance, contrairement aux snapshots automatisés qui sont supprimés avec l’instance après un délai de grâce de 7 jours. Utilisés pour des jalons (avant migration, avant mise à niveau majeure) et pour la rétention long terme au-delà de la fenêtre automatisée.

Copies de snapshots inter-régions. Copie manuelle ou automatisée d’un snapshot vers une autre région. Requise pour tout scénario DR où la région source est indisponible. La copie est incrémentale après la première, mais la première est une copie complète et peut prendre des heures pour de grosses bases.

Les scénarios de récupération qu’ils couvrent :

Scénario	Mécanisme de récupération	RTO typique
Table droppée, découverte en heures	PITR au moment juste avant le drop	30–60 min
Bug applicatif a corrompu les données sur une journée	PITR ; restauration avant la fenêtre de corruption	30–90 min
Crash d’instance de base	Basculement Multi-AZ (pas sauvegarde)	30–90s
Corruption de volume de stockage	Restauration du dernier snapshot automatisé, replay WAL	1–4 heures
Suppression accidentelle d’instance	Restauration depuis snapshot automatisé (dans le délai de 7 jours)	1–4 heures
Panne régionale	Snapshot inter-régions ou Aurora Global Database	4–24 heures depuis snapshot ; 5–15 min depuis Global
Récupération conformité long terme	Snapshot manuel conservé des années	Heures (selon la taille)
Cas limite snapshot-pendant-basculement	Attendre fin du basculement, reprendre	Plusieurs minutes de délai

La stratégie échoue de trois façons courantes. Premièrement, la rétention est trop courte — BackupRetentionPeriod à 1 jour signifie « si on ne remarque pas le problème d’ici demain matin, les données sont perdues ». Deuxièmement, les snapshots restent dans la région source — un événement régional emporte la base et les sauvegardes ensemble. Troisièmement, personne n’a réellement restauré depuis un snapshot, donc le jour où une vraie restauration est nécessaire, l’équipe apprend que les permissions IAM manquent, les références aux security groups sont obsolètes, ou le parameter group est parti.

Comment vérifier

Vérifiez la posture sauvegarde actuelle :

aws rds describe-db-instances \
  --db-instance-identifier prod-db-1 \
  --query 'DBInstances[].[DBInstanceIdentifier,BackupRetentionPeriod,LatestRestorableTime,BackupWindow,CopyTagsToSnapshot]' \
  --output table

Pour Aurora :

aws rds describe-db-clusters \
  --db-cluster-identifier prod-aurora-1 \
  --query 'DBClusters[].[DBClusterIdentifier,BackupRetentionPeriod,EarliestRestorableTime,LatestRestorableTime,PreferredBackupWindow]' \
  --output table

LatestRestorableTime moins EarliestRestorableTime est votre vraie fenêtre PITR. Si LatestRestorableTime est en retard de plus de quelques minutes par rapport à maintenant, le journal de transactions est en retard — fréquent durant des écritures lourdes ou durant une opération snapshot, mais à investiguer si cela persiste.

Listez les snapshots dans la région source :

aws rds describe-db-snapshots \
  --db-instance-identifier prod-db-1 \
  --snapshot-type automated \
  --query 'DBSnapshots[].[DBSnapshotIdentifier,SnapshotCreateTime,Status,EngineVersion]' \
  --output table

Et dans la région DR :

aws rds describe-db-snapshots \
  --region us-west-2 \
  --query 'DBSnapshots[?contains(DBSnapshotIdentifier, `prod-db-1`)].[DBSnapshotIdentifier,SnapshotCreateTime,Status,SourceRegion]' \
  --output table

Si la requête région DR retourne vide, vous n’avez pas de récupération inter-régions.

Confirmez les clés KMS inter-régions (un piège fréquent). Les snapshots chiffrés avec une CMK région-source ne peuvent pas être copiés vers une autre région sans re-chiffrement avec une CMK région-destination :

aws rds describe-db-snapshots \
  --db-instance-identifier prod-db-1 \
  --query 'DBSnapshots[?Encrypted==`true`].[DBSnapshotIdentifier,KmsKeyId]' \
  --output table

La clé KMS dans la sortie est une clé région-source. Pour la copie inter-régions, la destination a besoin d’une CMK dans la région destination, et la commande de copie la spécifie.

La correction

Le drill de restauration trimestriel — le runbook que l’équipe doit parcourir qu’elle le veuille ou non.

Étape 1 — Choisir un horaire et avertir les parties prenantes. Un drill restaure vers une nouvelle instance ; il n’affecte pas la production. Planifiez une fenêtre de 2 heures. Avertissez le propriétaire de l’application pour qu’il ne panique pas en voyant l’instance de drill apparaître dans la console.

Étape 2 — Choisir la cible. Un point-in-time il y a 4 heures. Assez récent pour tester des données de charge réelles, assez ancien pour que le PITR teste le chemin de replay WAL et non juste « restaurer le dernier snapshot ».

Étape 3 — Restaurer. Pour RDS :

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-db-1 \
  --target-db-instance-identifier prod-db-1-drill-$(date +%Y%m%d) \
  --restore-time "$(date -u -v-4H +%Y-%m-%dT%H:%M:%S)" \
  --db-subnet-group-name drill-subnet-group \
  --vpc-security-group-ids sg-drill \
  --db-parameter-group-name prod-db-1-pg \
  --no-publicly-accessible

Pour Aurora :

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier prod-aurora-1 \
  --db-cluster-identifier prod-aurora-1-drill-$(date +%Y%m%d) \
  --restore-to-time "$(date -u -v-4H +%Y-%m-%dT%H:%M:%S)" \
  --db-subnet-group-name drill-subnet-group \
  --vpc-security-group-ids sg-drill

Suivi d’une création d’instance dans le cluster :

aws rds create-db-instance \
  --db-instance-identifier prod-aurora-1-drill-writer \
  --db-cluster-identifier prod-aurora-1-drill-$(date +%Y%m%d) \
  --db-instance-class db.r6g.large \
  --engine aurora-postgresql

Étape 4 — Vérifier. Connectez-vous, exécutez une requête smoke test, confirmez que les données sont au point dans le temps attendu :

SELECT max(created_at) FROM orders;
-- devrait être approximativement il y a 4 heures
SELECT count(*) FROM users;
-- devrait être proche mais légèrement inférieur à la production

Étape 5 — Chronométrer. Le temps total de l’appel API à « l’application peut se connecter et lire des données » est le RTO de récupération pour ce scénario. Notez-le. Le drill qui prend 90 minutes est informatif ; le drill qui prend 8 heures parce que IAM et security groups étaient mal configurés est un problème à corriger avant le prochain drill.

Étape 6 — Démanteler. L’instance de drill est jetable. Supprimez-la avec --skip-final-snapshot :

aws rds delete-db-instance \
  --db-instance-identifier prod-db-1-drill-$(date +%Y%m%d) \
  --skip-final-snapshot \
  --delete-automated-backups

Trois choses qui mordent durant de vraies restaurations :

Le piège snapshot-pendant-basculement. Un snapshot automatisé planifié pour démarrer à 02:00 ne peut pas démarrer si un basculement est en cours. Le snapshot est retardé, parfois de plusieurs heures. La LatestRestorableTime continue d’avancer parce que PITR continue, mais le nouveau snapshot n’apparaît pas. Si l’équipe vérifie « on a un snapshot de ce matin » sans vérifier l’heure, elle découvre le trou pendant le prochain incident.

Dérive du parameter group. Une restauration PITR crée une nouvelle instance avec le parameter group par défaut sauf si vous passez --db-parameter-group-name. Une production tunée avec des paramètres custom restaure vers une configuration vanille et exhibe une performance différente. Le drill attrape cela ; les restaurations de production sous stress le manquent souvent.

Permissions KMS inter-régions. La copie de snapshot inter-régions exige des grants KMS sur les clés source et destination. Le principal IAM qui exécute la copie a besoin de kms:CreateGrant sur la clé destination, kms:Decrypt sur la clé source, et la clé destination doit autoriser le service principal RDS. Environ une configuration inter-régions sur trois que nous auditons a une de ces trois éléments manquant.

La stratégie de rétention que nous exécutons par défaut pour la production :

BackupRetentionPeriod : 14 jours (la fenêtre PITR opérationnelle).
Copie de snapshot automatisé quotidienne vers une seconde région (la fenêtre catastrophe régionale).
Snapshot manuel hebdomadaire, conservé 12 mois (la fenêtre conformité long terme).
Snapshot manuel trimestriel, conservé 7 ans (la fenêtre audit).

La cadence des drills :

Trimestriel : drill PITR vers un point il y a 4 heures dans la région source. Chronométrer la récupération.
Annuel : drill de restauration inter-régions complet depuis le snapshot région DR. Vérifier réseau, IAM, connectivité applicative.
Annuel : vérification d’intégrité de snapshot long terme — choisir un snapshot manuel de 6 mois, le restaurer, vérifier que le schéma et un échantillon de données sont intacts.

Trois règles que nous tenons sur tout engagement de sauvegarde :

Un snapshot que vous n’avez pas restauré n’existe pas. L’équipe ne sait que la restauration marche que quand elle l’a parcourue. Le premier drill de restauration sur un nouvel environnement expose plus de problèmes que les vingt suivants.

L’inter-régions n’est pas optionnel pour la production. Le coût d’une copie de snapshot quotidienne est petit. Le coût d’être verrouillé à une région durant un événement régional, c’est l’entreprise.

La rétention est fonction du temps que vous pourriez ne pas remarquer un problème. Une équipe qui livre toutes les nuits et surveille la supervision de près a besoin de 14 jours. Une équipe qui fait une réconciliation comptable mensuelle contre des données historiques a besoin de 90 jours. Choisissez le nombre selon la capacité de l’équipe à détecter les problèmes, pas selon le défaut AWS.

Toute la stratégie est mécanique une fois construite. La partie difficile est la discipline de la répéter trimestriellement quand l’équipe a d’autres priorités. C’est la partie qui paie le jour où le moment arrive.

Stack Harbor conçoit et opère les topologies RDS / Aurora en production dans le cadre de Gestion AWS et de la couche Environnements infogérés. Si votre posture base de données se résume à « case Multi-AZ cochée + espoir », commencez par une consultation d’infrastructure.