Industrialiser les sauvegardes et la reprise

Les étapes

1. Étape 1
   TutorielNouveau

   Automatiser la sauvegarde d'une base PostgreSQL vers S3

   L'équipe data d'une fintech de Douala conserve ses sauvegardes PostgreSQL sur le disque du serveur applicatif. Une panne disque en juillet a coûté deux jours de transactions : la direction exige désormais des sauvegardes quotidiennes, chiffrées, stockées hors du serveur et vérifiables. Dans ce scénario, vous reprenez l'infrastructure là où elle en est : une base PostgreSQL de paiements qui reçoit une nouvelle transaction toutes les deux secondes, et un bucket S3 vide. À vous de construire la chaîne de sauvegarde complète — extraction avec pg_dump, chiffrement, dépôt sur S3, rotation des anciennes copies et alerte en cas d'échec. La sandbox est prête : PostgreSQL, l'AWS CLI et un rôle IAM limité à votre bucket sont déjà en place, et vous ouvrez le terminal directement dans votre navigateur, sans clé SSH. Vous passez la séance sur la logique de sauvegarde, pas sur l'installation des outils. À la fin, vous supprimez volontairement une table et prouvez que votre sauvegarde permet de repartir.

   • 4,3 sur 5, (3 avis)
   • Intermédiaire
   • 1 h 40 min
   • 500 crédits
2. Étape 2
   AvancéNouveau

   Restaurer une base PostgreSQL après incident et mesurer le RTO

   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.

   • Aucun avis
   • Avancé
   • 2 h
   • 1 000 crédits
3. Étape 3
   AvancéNouveau

   Récupérer une base PostgreSQL à la minute près après une erreur humaine

   Lundi 14 h 07, un script de migration passe en production. Il devait régulariser les paiements du week-end ; sa dernière requête a perdu sa clause WHERE à la relecture. Personne ne le voit. À 15 h 30, le rapprochement bancaire ne tombe plus : toutes les transactions portent un montant à zéro. Vous restaurez le dump de 2 h du matin, le service repart, et treize heures d'encaissements disparaissent avec la bêtise. Les deux premiers labs du parcours ont réglé le temps de remise en service. Celui-ci s'attaque à l'autre chiffre, celui que personne n'avait demandé : la quantité de données perdues. Avec une sauvegarde par jour, aucune restauration, aussi rapide soit-elle, ne descend sous 24 heures de pertes — ce qui n'a pas été sauvegardé n'existe plus. Il faut changer de mécanisme. Vous mettez en place l'archivage continu des journaux de transactions vers S3, puis vous le prouvez sur un incident que vous déclenchez vous-même : vous relancez le script fautif sur une base vivante, et vous la ramenez à la seconde d'avant. Un plan de reprise qu'on n'a jamais répété n'est pas un plan, c'est un espoir. La sandbox démarre avec la production en marche — une transaction toutes les deux secondes — le dump de 02 h 00 déjà sur S3, et l'archivage des WAL à construire.

   • Aucun avis
   • Avancé
   • 2 h 30 min
   • 1 000 crédits