Aller au contenu

AWS Mis à jour le 2026-07-04

Restaurer un snapshot RDS correctement : la surprise de la nouvelle instance et ce qui ne revient pas

Restaurer un snapshot RDS crée toujours une nouvelle instance — et les parameter groups, security groups et option groups ne la suivent pas. Le runbook de restauration qui évite les surprises classiques.

Vous ne pouvez pas restaurer un snapshot RDS sur une instance existante. Une restauration crée toujours une instance flambant neuve avec un nouvel endpoint — et sauf indication contraire, cette nouvelle instance démarre avec le parameter group par défaut et le security group par défaut du VPC, pas ceux que votre instance de production utilise. La plupart des incidents « la restauration a marché mais l’application est cassée » sont exactement ça : les données sont revenues correctement, la configuration autour, non.

Ce qui se passe

Un snapshot RDS est une copie au niveau stockage du volume de la base plus un peu de métadonnées : moteur, version, type de stockage, et quel option group s’applique. Ce n’est pas une copie de la configuration complète de l’instance. Quand vous lancez une restauration, RDS construit une instance neuve à partir de ce volume et vous demande (ou applique des valeurs par défaut) pour tout le reste :

  • Parameter group — si vous n’en passez pas un, la nouvelle instance reçoit le parameter group par défaut de la famille du moteur. Vos réglages ajustés de max_connections, shared_buffers ou innodb_buffer_pool_size disparaissent, ce qui explique pourquoi l’instance restaurée « semble plus lente » ou refuse les connexions sous charge.
  • Security groups — l’instance restaurée s’attache au security group par défaut du VPC cible à moins que vous ne spécifiiez les vôtres. Les SG par défaut ne permettent habituellement rien en entrée depuis vos sous-réseaux applicatifs, donc l’application ne peut tout simplement pas se connecter.
  • Subnet group et VPC — vous choisissez au moment de la restauration; restaurer dans le mauvais subnet group place la base là où votre application ne peut pas l’atteindre.
  • Endpoint — la nouvelle instance reçoit un nouveau nom DNS. Rien de ce que vous restaurez ne répondra à l’ancien nom d’hôte tant que vous ne l’aurez pas arrangé.
  • Option groups — pour Oracle et SQL Server, des options comme la sauvegarde/restauration native ou TDE vivent dans l’option group et doivent être compatibles; une incompatibilité bloque la restauration.

Le chiffrement suit le snapshot : un snapshot chiffré se restaure en instance chiffrée avec la même clé KMS par défaut, et si cette clé est une clé gérée par le client dans un autre compte, la politique de clé doit vous le permettre — les pièges sont couverts dans le chiffrement RDS avec clés KMS gérées par le client. Ce qu’une restauration de snapshot ne peut pas faire non plus, c’est vous donner un point entre deux snapshots; pour ça, il faut la restauration à un instant précis. La matrice complète des options de restauration est dans la documentation RDS sur https://docs.aws.amazon.com/rds/.

Quoi vérifier en premier

  • Quel snapshot, exactement — automatisé vs manuel, son heure de création, et si cet horodatage couvre vraiment ce que vous essayez de récupérer.
  • Le parameter group, les security groups et le subnet group de l’instance de production — vous aurez besoin de leurs noms pour la commande de restauration.
  • La clé KMS — snapshot chiffré? Confirmez que vous pouvez utiliser la clé, surtout inter-comptes ou inter-régions.
  • Classe d’instance et marge de stockage — restaurer vers une classe plus petite que ce que la charge exige rend le « test » invalide.
  • Qui consomme l’endpoint — configuration applicative, chaînes de connexion dans Secrets Manager, tout ce qui est codé en dur.

Comment vérifier

Listez les snapshots candidats et leurs métadonnées :

aws rds describe-db-snapshots \
  --db-instance-identifier prod-db \
  --query 'DBSnapshots[].[DBSnapshotIdentifier,SnapshotCreateTime,SnapshotType,Encrypted,Status]' \
  --output table

Capturez la configuration de production que vous devez rattacher :

aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].[DBParameterGroups[0].DBParameterGroupName,VpcSecurityGroups[].VpcSecurityGroupId,DBSubnetGroup.DBSubnetGroupName,DBInstanceClass]'

Après une restauration, la console montre l’écart clairement : RDS > Databases > (instance restaurée) > Configuration liste le parameter group et les security groups réellement attachés — comparez avec la production avant de crier victoire.

La marche à suivre

  1. Restaurez avec la configuration énoncée explicitement. Ne comptez pas sur les valeurs par défaut :

    aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier prod-db-restored \
  --db-snapshot-identifier rds:prod-db-2026-07-03-06-08 \
  --db-instance-class db.r6g.xlarge \
  --db-subnet-group-name prod-db-subnets \
  --vpc-security-group-ids sg-0abc123def456 \
  --db-parameter-group-name prod-pg16-params \
  --no-publicly-accessible

  2. Attendez available, puis redémarrez si les paramètres l’exigent. Les paramètres statiques appliqués à la restauration ont besoin d’un redémarrage; vérifiez « pending-reboot » dans Configuration.

  3. Validez les données avant de toucher au trafic. Connectez-vous depuis un bastion ou un hôte applicatif, vérifiez les tables et les horodatages les plus récents que le snapshot était censé contenir.

  4. Basculez les applications délibérément. Deux options propres : mettre à jour la chaîne de connexion (Secrets Manager ou configuration) vers le nouvel endpoint, ou faire la valse des renommages — renommer l’ancienne instance pour la tasser, puis renommer la restaurée avec l’ancien identifiant pour que le nom d’hôte de l’endpoint soit régénéré à l’identique. L’approche par renommage garde la configuration applicative intacte mais comporte une brève fenêtre où le nom ne résout vers rien; drainez le trafic d’abord.

  5. Repointez sauvegardes, surveillance et alarmes. Les alarmes CloudWatch, Performance Insights et les plans de sauvegarde référencent l’identifiant d’instance — une instance renommée ou neuve leur est invisible tant que vous ne les rattachez pas.

  6. Retirez l’ancienne instance selon un échéancier, pas immédiatement. Gardez-la arrêtée ou en snapshot, donnez-lui une date de suppression, et prenez un snapshot final quand cette date arrive.

Quand c’est la mauvaise approche

Si vous avez besoin de l’état de 14 h 32 hier et que vos snapshots tournent la nuit, une restauration de snapshot vous remet les mauvaises données — utilisez plutôt la restauration à un instant précis, qui rejoue les journaux de transactions à la seconde. Si une seule table a été endommagée, restaurer toute l’instance et copier cette table reste le mécanisme, mais demandez-vous si un export logique de cette table depuis la copie restaurée est plus rapide qu’une bascule complète. Et une restauration de snapshot n’est pas une stratégie de clonage pour Aurora — les clones rapides Aurora font ça en minutes sans dupliquer le stockage.

Erreurs courantes

  • Restaurer avec les valeurs par défaut et passer une heure à déboguer un « connection refused » qui n’est que le security group par défaut faisant son travail.
  • Oublier le parameter group, puis attribuer les mauvaises performances de l’instance restaurée à une « corruption de snapshot » qui n’existe pas.
  • Supprimer l’instance originale immédiatement après la bascule, avant que quiconque ait confirmé que les données restaurées sont vraiment complètes.
  • Tester des restaurations dans des sous-réseaux publics avec --publicly-accessible laissé actif, exposant une copie des données de production à Internet.

Prévention

  • Scriptez la restauration avec tous les indicateurs explicites, gardez-la dans le dépôt, et faites un exercice trimestriel — une restauration jamais répétée est une théorie, pas une capacité.
  • Étiquetez les snapshots et activez CopyTagsToSnapshot pour que les instances restaurées héritent des étiquettes de propriété et d’environnement.
  • Gardez parameter groups, security groups et subnet groups en infrastructure-as-code pour que leurs noms soient documentés et stables.
  • Documentez la procédure de bascule côté application (mise à jour du secret ou renommage) à côté du script de restauration; la moitié base de données n’est que la moitié de la restauration.

Une restauration de snapshot bien faite est ennuyante : configuration explicite en entrée, validation, bascule délibérée, nettoyage planifié. 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.