Aller au contenu

AWS Mis à jour le 2026-10-05

Sauvegarde et restauration RDS : viser la confiance en la reprise, pas l'espoir

Amazon RDS (Relational Database Service, le service de bases de données gérées d'AWS) active les sauvegardes automatiques pour vous, mais avoir des sauvegardes ne garantit pas que vous pourrez restaurer. Vérifiez jusqu'où vous pouvez remonter, chronométrez une restauration d'essai et confirmez que votre application fonctionne avec la copie restaurée.

Si la base de données de votre application tourne sur Amazon RDS (Relational Database Service, le service de bases de données gérées d’AWS), vous pouvez vérifier dès aujourd’hui si une restauration fonctionnerait vraiment le jour où vous en aurez besoin. Par défaut, RDS conserve habituellement sept jours de sauvegardes automatiques, prend un instantané chaque nuit et affiche tout au vert dans la console. Cela prouve que les sauvegardes existent, pas que vous pouvez restaurer à partir d’elles. La vraie confiance vient de trois réponses que vous pouvez vérifier vous-même. Jusqu’où pouvez-vous remonter dans le temps? Combien de temps prend une restauration pour votre base de données à sa taille actuelle? Et à quand remonte la dernière fois qu’une personne en a fait une et y a branché l’application? Les étapes ci-dessous couvrent chacune de ces questions, pour que vous trouviez les failles par un après-midi tranquille plutôt qu’en plein incident.

Ce qui se passe

RDS offre deux mécanismes de sauvegarde qui se comportent différemment, et les confondre cause la majorité de la confusion le jour d’une restauration. Les sauvegardes automatiques sont un instantané quotidien plus une capture continue des journaux de transactions, conservées de 1 à 35 jours; ce sont elles qui permettent la restauration à un instant précis (PITR) — revenir à n’importe quelle seconde dans la fenêtre, habituellement à environ cinq minutes derrière la base en direct. Les instantanés manuels sont des copies ponctuelles qui persistent jusqu’à leur suppression, survivent à la suppression de l’instance, et sont ce que vous copiez entre régions ou partagez entre comptes.

Le fait opérationnel qui surprend : une restauration ne répare jamais l’instance existante. Elle crée toujours une nouvelle instance avec un nouveau point de terminaison et, selon la façon de la lancer, avec le groupe de paramètres par défaut et le groupe de sécurité par défaut du VPC plutôt que ceux de la production. Votre application ne suit pas automatiquement — vous la repointez, ou vous renommez les instances. La durée de restauration n’est pas non plus celle qu’on imagine : la nouvelle instance devient disponible pendant que les blocs de données se chargent encore paresseusement depuis S3, donc la base répond aux requêtes mais tourne au ralenti tant que le jeu de travail n’a pas été rapatrié. Pour une grosse base, « disponible » et « performance normale » peuvent être séparés de plusieurs heures. Les deux comportements sont documentés dans la documentation RDS, mais presque personne ne la lit avant l’urgence.

Quoi vérifier en premier

  • La période de rétention. Un BackupRetentionPeriod à 0 signifie que les sauvegardes automatiques sont carrément désactivées — ça arrive, souvent à cause d’un vieux réglage Terraform par défaut.
  • LatestRestorableTime. C’est votre RPO réel en ce moment. S’il traîne des heures derrière au lieu de quelques minutes, l’expédition des journaux est en mauvais état.
  • La fenêtre de sauvegarde contre la charge. Sur une instance mono-AZ, l’instantané quotidien suspend brièvement les E/S; une fenêtre placée en pleines heures de pointe, c’est une douleur auto-infligée.
  • Où vivent les instantanés. Tout dans une seule région et un seul compte, et un incident régional ou des identifiants compromis emportent la base et ses sauvegardes ensemble.
  • La dernière vraie restauration. Si personne ne peut nommer une date, tenez pour acquis que le chemin de restauration cache des inconnues.

Comment vérifier

# Rétention, position PITR réelle et fenêtre de sauvegarde
aws rds describe-db-instances \
  --db-instance-identifier prod-db \
  --query 'DBInstances[0].[BackupRetentionPeriod,LatestRestorableTime,PreferredBackupWindow]'

# Instantané automatique le plus récent
aws rds describe-db-snapshots \
  --db-instance-identifier prod-db \
  --snapshot-type automated \
  --query 'sort_by(DBSnapshots,&SnapshotCreateTime)[-1].[DBSnapshotIdentifier,SnapshotCreateTime,Status]'

# Instantanés manuels (ils survivent à la suppression de l'instance)
aws rds describe-db-snapshots \
  --db-instance-identifier prod-db \
  --snapshot-type manual \
  --query 'DBSnapshots[].[DBSnapshotIdentifier,SnapshotCreateTime]'

Dans la console, la même information vit sous RDS > Automated backups et RDS > Snapshots. Pour Aurora, vérifiez le cluster plutôt que l’instance — les sauvegardes sont au niveau du cluster et continues, et la même question de LatestRestorableTime s’applique.

La marche à suivre

  1. Fixez la rétention volontairement. Sept jours est un plancher raisonnable en production; 35 est le plafond des sauvegardes automatiques. Tout ce qui est plus vieux que 35 jours doit venir d’instantanés manuels ou d’AWS Backup — décidez lequel et écrivez-le.
  2. Exécutez une restauration PITR vers une instance jetable. C’est le cœur de tout l’exercice :
aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-db \
  --target-db-instance-identifier prod-db-restore-drill \
  --use-latest-restorable-time \
  --db-instance-class db.t4g.medium \
  --no-multi-az

Chronométrez de la commande jusqu’à « utilisable par l’application », pas jusqu’à « instance disponible ». Connectez ensuite un client, vérifiez le nombre de lignes d’une table que vous connaissez, puis supprimez l’instance d’exercice. 3. Corrigez ce que l’exercice a exposé. Trouvailles typiques : l’instance restaurée est arrivée avec le groupe de paramètres par défaut (passez --db-parameter-group-name), le mauvais groupe de sécurité (passez --vpc-security-group-ids), ou dans le mauvais groupe de sous-réseaux. Intégrez les bons indicateurs dans une commande de restauration documentée. 4. Copiez les instantanés hors du rayon d’impact. Les instantanés automatiques ne peuvent pas être partagés; copiez vers un instantané manuel, puis copiez celui-ci vers une autre région ou partagez-le vers un compte de reprise. Pour les instantanés chiffrés, la destination doit avoir accès à la clé KMS — c’est l’étape qui échoue le jour où vous en avez besoin, alors testez-la maintenant. 5. Alarmez sur ce qui pourrit. LatestRestorableTime qui prend du retard, l’âge des instantanés, et la marge de stockage — une base qui remplit son stockage cesse d’accepter les écritures, et aucune sauvegarde ne règle ça. 6. Écrivez l’arbre de décision. Mauvais déploiement il y a cinq minutes : PITR juste avant le déploiement. Table supprimée hier : PITR vers une instance jetable, exportez la table, importez en production. Région en panne : promouvez la copie inter-région. La séquence d’exercice complète est dans Stratégie PITR et instantanés RDS / Aurora.

Quand c’est la mauvaise approche

Le PITR sert à la perte de données, pas à la disponibilité. Si l’instance elle-même meurt, le basculement Multi-AZ récupère en une minute ou deux sans toucher aux sauvegardes — restaurer depuis un instantané dans ce scénario jette des heures par la fenêtre pour rien; les compromis sont expliqués dans Multi-AZ ou multi-région pour RDS. Si votre RPO est effectivement zéro, les sauvegardes sont la deuxième ligne et la réplication la première. Et si la corruption est logique et ancienne — de mauvaises données écrites il y a trois semaines dans une fenêtre de 7 jours — aucun mécanisme RDS ne s’y rend; c’est le rôle des instantanés manuels à longue rétention ou des exportations.

Erreurs courantes

  • Croire qu’une restauration répare l’instance en place. Elle en crée une nouvelle; la bascule — changement de point de terminaison ou renommage — vous appartient et doit figurer dans le cahier d’exploitation.
  • Juger le temps de restauration par le statut de l’instance. « Available » arrive bien avant la performance normale sur les grosses bases, parce que les blocs se chargent paresseusement depuis S3.
  • Supprimer une instance sans instantané final. Sautez-le et les sauvegardes automatiques peuvent partir avec l’instance (la rétention des sauvegardes d’instances supprimées dépend des réglages) — prenez l’instantané final chaque fois.
  • Instantané chiffré, aucun accès à la clé à destination. Les copies inter-compte et inter-région d’instantanés chiffrés échouent sans droits KMS, qui doivent être arrangés d’avance.

Prévention

  • Mettez le retard de LatestRestorableTime sur un tableau de bord à côté du retard de réplication.
  • Faites l’exercice de restauration chaque trimestre; gardez le résultat chronométré à côté du RTO écrit.
  • Conservez une commande de restauration documentée, prête à copier-coller, avec le bon groupe de paramètres, les bons groupes de sécurité et le bon groupe de sous-réseaux déjà remplis.
  • Automatisez la copie d’instantané manuel vers une deuxième région ou un deuxième compte plutôt que de compter sur la mémoire de quelqu’un.
  • Retestez le chemin KMS chaque fois que les clés ou leurs politiques changent.

Une équipe qui a confiance en sa reprise peut dire « on restaure en environ 40 minutes et on perd au plus 5 minutes de données » et le prouver avec un journal d’exercice daté. 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.