AvancéNouveauParcours : Industrialiser les sauvegardes et la reprise
Restaurer une base après incident et mesurer le RTO
- Aucun avis
- Avancé
- 2 h
- 600 LC
Par Équipe MonPremierLab
Description
Il est 6 h du matin, la base de paiements ne redémarre plus et le directeur technique vous demande une seule chose : dans combien de temps le service est rétabli. Vous disposez des sauvegardes chiffrées déposées sur S3 la veille et d'un serveur de secours vierge. Ce scénario enchaîne sur la chaîne de sauvegarde du lab précédent, mais du côté qui compte vraiment : la restauration. Vous récupérez l'archive, la déchiffrez, remontez la base sur le serveur de secours, rebasculez le trafic applicatif et chiffrez le tout en un temps que vous mesurez. La sandbox démarre avec l'incident déjà survenu : la base principale est corrompue, les sauvegardes sont en place, le chronomètre tourne.
Important
Le chronomètre du scénario démarre à l'ouverture de la sandbox : notez l'heure de départ avant toute autre action, le compte rendu final vous la redemandera.
Conseil
Avant de restaurer, prenez trente secondes pour copier la base corrompue ailleurs. Une restauration ratée sur la seule copie restante transforme un incident en catastrophe.
Compétences travaillées
- Qualifier un incident de base de données avant d'agir
- Récupérer et déchiffrer une sauvegarde déposée sur S3
- Restaurer une base PostgreSQL sur un serveur de secours
- Rebasculer le trafic applicatif sans perte de transaction
- Mesurer un RTO réel et l'écrire dans un compte rendu d'incident
Technologies utilisées
- PostgreSQL
- pg_restore
- Amazon S3
- AWS KMS
- systemd
Prérequis
- Avoir terminé le lab « Automatiser la sauvegarde d'une base PostgreSQL vers S3 »
- Être à l'aise avec la ligne de commande Linux sous pression
- postgresql
- restauration
- pra
- rto
- incident
En bref
- Domaine
- Données et analytique
- Niveau
- Avancé
- Durée estimée
- 2 h
- Sandbox
- 4 h, puis suppression automatique
- Langue
- Français
- Mis à jour le
- 16 septembre 2026