🔝 Retour au Sommaire
Imaginez-vous un lundi matin. Vous arrivez au bureau avec votre café, prêt à attaquer la semaine. Vous allumez votre ordinateur et découvrez que votre serveur PostgreSQL de production est complètement inaccessible.
- Le datacenter a pris feu pendant la nuit 🔥
- Un ransomware a chiffré toutes vos données 🔒
- Une erreur humaine a supprimé la base de données principale 🗑️
- Une inondation a noyé la salle serveur 🌊
Qu'allez-vous faire ? Comment allez-vous récupérer vos données ? Combien de temps faudra-t-il pour remettre le service en ligne ? Combien de données allez-vous perdre ?
C'est exactement à ces questions que répond le Disaster Recovery (récupération après sinistre en français, abrégé DR).
Le Disaster Recovery est l'ensemble des politiques, procédures, outils et processus qui permettent de récupérer et de protéger votre infrastructure informatique (ici, votre base de données PostgreSQL) en cas de catastrophe majeure.
En d'autres termes : c'est votre plan de survie pour votre base de données.
Voici quelques statistiques qui montrent l'importance cruciale du DR :
| Statistique | Impact |
|---|---|
| 93% des entreprises qui perdent leurs données pendant plus de 10 jours font faillite dans l'année | Source : National Archives & Records Administration |
| 60% des PME ferment dans les 6 mois suivant une perte de données majeure | Source : University of Texas |
| Coût moyen d'un downtime : 5 600€ par minute pour une grande entreprise | Source : Gartner 2024 |
| 81% des cyberattaques ciblent les bases de données | Source : Verizon DBIR 2024 |
| 40% des entreprises n'ont pas de plan DR formalisé | Source : IDC Research |
Conclusion : Ne pas avoir de plan DR, c'est jouer à la roulette russe avec votre entreprise.
Un désastre n'est pas forcément un événement catastrophique comme un incendie. Voici les principaux types de désastres que vous devez anticiper :
- Incendies : Exemple célèbre - OVH Strasbourg (mars 2021), 3,6 millions de sites affectés
- Inondations : Datacenters en sous-sol particulièrement vulnérables
- Tremblements de terre : Risque dans certaines régions (Japon, Californie, Italie)
- Ouragans, tornades : Dommages aux infrastructures électriques et réseau
- Pannes électriques prolongées : Texas (février 2021), plusieurs jours sans électricité
Impact typique : Perte totale du datacenter, indisponibilité de plusieurs jours à semaines.
- Suppression accidentelle :
DROP DATABASE production;au lieu deDROP DATABASE test; - Mauvaise migration : Script SQL qui corrompt les données
- Mauvaise configuration : Modification de postgresql.conf qui empêche le démarrage
- Oubli de backup : Les sauvegardes n'ont pas été vérifiées depuis des mois
Statistique : 30-40% des incidents de production sont dus à l'erreur humaine (source : ITIC).
Exemple réel :
-- Scénario : Un développeur se trompe de console
-- Il pense être sur la base de test...
psql -h production-db.example.com -U admin
-- ... mais il est en réalité sur la production
DELETE FROM orders WHERE created_at < '2024-01-01';
-- Catastrophe : 500 000 commandes supprimées !
-- Sans backup récent = perte définitive- Défaillance disque : SSD/HDD qui lâchent sans préavis
- Corruption mémoire : RAM défectueuse qui corrompt les données
- Panne alimentation : Sans onduleur, corruption des données en cours d'écriture
- Surchauffe : Climatisation défaillante → arrêt d'urgence des serveurs
- Défaillance contrôleur RAID : Perte de plusieurs disques simultanément
Durée de vie moyenne :
- Disque SSD : 5-7 ans
- Disque HDD : 3-5 ans
- Serveur : 5-7 ans
Vous ALLEZ avoir une panne matérielle. Ce n'est qu'une question de temps.
- Ransomware : Chiffrement de toutes vos données avec demande de rançon
- Attaque DDoS : Saturation du serveur, impossibilité d'accès
- Injection SQL : Destruction ou vol de données
- Accès non autorisé : Ancien employé mécontent qui supprime des données
- Crypto-mining : Serveur compromis utilisé pour miner de la crypto
Exemple de ransomware :
┌────────────────────────────────────────────────┐
│ 🔒 YOUR DATABASE HAS BEEN ENCRYPTED │
│ │
│ All your PostgreSQL data is locked. │
│ Pay 50 BTC to recover your files. │
│ │
│ Bitcoin Address: 1A1zP1eP5QGefi2DM... │
│ Time remaining: 48 hours │
│ │
│ After 48h, data will be deleted forever. │
└────────────────────────────────────────────────┘
Ne payez JAMAIS la rançon. Avec un bon plan DR, vous pouvez restaurer sans payer.
- Bug dans PostgreSQL : Rare mais possible (corruption de données)
- Bug dans l'application : Boucle infinie qui corrompt les données
- Migration ratée : Upgrade de PostgreSQL 17 → 18 qui échoue
- Incompatibilité : Extension qui cause des crashs répétés
- Saisie de serveurs : Dans le cadre d'une enquête
- Fermeture administrative : Non-conformité RGPD
- Événements géopolitiques : Guerre, instabilité politique dans le pays hébergeur
- Faillite de l'hébergeur : Datacenter fermé du jour au lendemain
Un plan DR complet pour PostgreSQL comprend plusieurs éléments interconnectés :
Question clé : Comment et à quelle fréquence sauvegardez-vous vos données ?
Types de backup PostgreSQL :
┌─────────────────────────────────────────────────────┐
│ 1. Sauvegardes Logiques (pg_dump) │
│ ✅ Flexible, portable │
│ ❌ Lent pour grandes bases │
│ Fréquence : Quotidienne pour bases < 100 GB │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ 2. Sauvegardes Physiques (pg_basebackup) │
│ ✅ Rapide, idéal pour grandes bases │
│ ❌ Dépendant de la version PostgreSQL │
│ Fréquence : Quotidienne ou hebdomadaire │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ 3. Archivage WAL (Write-Ahead Logs) │
│ ✅ Point-in-Time Recovery (PITR) │
│ ✅ RPO minimal (< 1 minute possible) │
│ Fréquence : Continu (temps réel) │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ 4. Snapshots (Cloud ou SAN) │
│ ✅ Très rapide (secondes) │
│ ❌ Dépendant de l'infrastructure │
│ Fréquence : Horaire ou plus │
└─────────────────────────────────────────────────────┘
Question clé : Avez-vous des copies en temps réel de vos données ?
┌───────────────────────────────────────────────┐
│ PRIMARY SERVER │
│ (Paris - Production) │
│ │
│ ┌─────────────────────────────────┐ │
│ │ PostgreSQL 18 │ │
│ │ Read + Write │ │
│ └──────────────┬──────────────────┘ │
│ │ │
└─────────────────┼─────────────────────────────┘
│
│ Streaming Replication
│ (WAL shipping)
│
┌─────────┴─────────┐
↓ ↓
┌───────────────┐ ┌───────────────┐
│ STANDBY #1 │ │ STANDBY #2 │
│ (Paris) │ │ (Londres) │
│ Read-only │ │ Read-only │
│ │ │ │
│ Hot Standby │ │ Warm Standby │
└───────────────┘ └───────────────┘
Types de réplication :
- Streaming Replication : Réplication en temps quasi-réel (< 1 seconde)
- Logical Replication : Réplication sélective (certaines tables)
- Physical Replication : Copie bit à bit du serveur
Question clé : Savez-vous immédiatement quand quelque chose ne va pas ?
Métriques critiques à surveiller :
┌─────────────────────────────────────────────────────┐
│ 🔴 CRITICAL ALERTS │
├─────────────────────────────────────────────────────┤
│ • PostgreSQL down │
│ • Replication lag > 60 secondes │
│ • Disk usage > 90% │
│ • Backup failed │
│ • Corruption détectée (checksums) │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ ⚠️ WARNING ALERTS │
├─────────────────────────────────────────────────────┤
│ • Replication lag > 10 secondes │
│ • Disk usage > 80% │
│ • Connections > 80% max_connections │
│ • Backup duration > 2× normal │
│ • WAL archiving delayed │
└─────────────────────────────────────────────────────┘
Question clé : Savez-vous exactement comment restaurer vos données ?
Un bon plan DR inclut des runbooks (procédures documentées) détaillés pour chaque scénario :
RUNBOOK : Restauration complète après sinistre
Scénario : Serveur PostgreSQL production détruit
RTO cible : 2 heures
RPO cible : 15 minutes
═══════════════════════════════════════════════════════
ÉTAPE 1 : ÉVALUATION (0-5 minutes)
──────────────────────────────────
[ ] Confirmer que le serveur est vraiment down
[ ] Identifier la cause (hardware, réseau, logiciel)
[ ] Décider : réparer ou restaurer ?
[ ] Déclarer l'incident (war room)
ÉTAPE 2 : PRÉPARATION (5-15 minutes)
──────────────────────────────────
[ ] Provisionner nouveau serveur (ou utiliser standby)
[ ] Vérifier accès réseau et DNS
[ ] Préparer environnement PostgreSQL
ÉTAPE 3 : RESTAURATION (15-90 minutes)
──────────────────────────────────
[ ] Télécharger dernier backup base
[ ] Extraire le backup
[ ] Restaurer les WAL archives (PITR)
[ ] Configurer PostgreSQL
[ ] Démarrer PostgreSQL
ÉTAPE 4 : VALIDATION (90-110 minutes)
──────────────────────────────────
[ ] Vérifier intégrité des données
[ ] Tester requêtes critiques
[ ] Valider avec équipe métier
[ ] Vérifier performances
ÉTAPE 5 : BASCULE (110-120 minutes)
──────────────────────────────────
[ ] Rediriger le trafic (DNS/Load balancer)
[ ] Surveiller les métriques
[ ] Communiquer aux utilisateurs
CONTACTS URGENCE :
─────────────────
• DBA Lead : +33 6 12 34 56 78
• DevOps : +33 6 98 76 54 32
• CTO : +33 6 11 22 33 44Question clé : Avez-vous testé votre plan DR récemment ?
Règle d'or : Une procédure DR non testée n'est pas une procédure DR, c'est une théorie.
Fréquence recommandée des tests :
- Tests de backup : Hebdomadaire (automatisé)
- Tests de restauration : Mensuel ou trimestriel
- Disaster Recovery Drill complet : Semestriel ou annuel
Question clé : Toute l'équipe sait-elle quoi faire en cas de crise ?
Éléments essentiels :
- Diagrammes d'architecture à jour
- Runbooks détaillés pour chaque scénario
- Contacts d'urgence (on-call rotation)
- Accès d'urgence (credentials, VPN, serveurs)
- Formation régulière de l'équipe
- Post-mortems après chaque incident
C'est une règle fondamentale en Disaster Recovery :
┌─────────────────────────────────────────────────────┐
│ RÈGLE 3-2-1 │
├─────────────────────────────────────────────────────┤
│ │
│ 3️⃣ Gardez AU MOINS 3 COPIES de vos données │
│ (1 originale + 2 backups) │
│ │
│ 2️⃣ Sur AU MOINS 2 TYPES de supports différents │
│ (disque local + cloud S3, ou NAS + tape) │
│ │
│ 1️⃣ Dont AU MOINS 1 COPIE hors site (off-site) │
│ (datacenter différent, région géographique) │
│ │
└─────────────────────────────────────────────────────┘
Exemple d'application pour PostgreSQL :
COPIE 1 : Production Database (Primary)
└─ Serveur : Paris Datacenter
└─ Support : SSD local
COPIE 2 : Backup quotidien
└─ Serveur : NAS dans le même datacenter
└─ Support : Disques durs (RAID 6)
COPIE 3 : Backup cloud
└─ Serveur : AWS S3 (région eu-west-1)
└─ Support : Object storage
COPIE BONUS : Réplication
└─ Serveur : Standby à Londres (autre datacenter)
└─ Support : SSD local
Pourquoi cette règle est importante :
| Scénario de désastre | Protection |
|---|---|
| 🔥 Incendie datacenter Paris | ✅ Copie #3 (S3) + Copie Bonus (Londres) OK |
| 💾 Défaillance disque local | ✅ Copies #2 et #3 OK |
| 🦹 Ransomware qui chiffre tout | ✅ Copie #3 (S3 avec versioning) OK |
| 👤 Suppression accidentelle | ✅ Toutes les copies peuvent restaurer |
| 🌊 Inondation datacenter | ✅ Copie #3 (autre région) OK |
Benchmark par taille d'entreprise (estimation mensuelle) :
Base de données : < 100 GB
RTO acceptable : 4-8 heures
RPO acceptable : 1-4 heures
COÛTS :
• Backup S3 (100 GB) : 3€/mois
• Serveur standby (petit) : 50€/mois
• Temps équipe (setup + maintenance) : 200€/mois
──────────────────────────────────────
TOTAL : ~250€/mois (~3000€/an)
Base de données : 500 GB - 2 TB
RTO acceptable : 1-2 heures
RPO acceptable : 15 minutes
COÛTS :
• Backup S3 (2 TB + archives) : 80€/mois
• Serveur standby (équivalent prod) : 600€/mois
• Monitoring (Datadog, New Relic) : 150€/mois
• Outils DR (pgBackRest, Patroni) : 0€ (open-source)
• Temps équipe (1 DevOps 20%) : 1000€/mois
──────────────────────────────────────
TOTAL : ~1830€/mois (~22 000€/an)
Base de données : 5+ TB
RTO acceptable : 15-30 minutes
RPO acceptable : 0-5 minutes
COÛTS :
• Backup multi-région (10 TB) : 400€/mois
• 2× Serveurs standby (multi-région) : 2500€/mois
• Monitoring enterprise : 800€/mois
• Data transfer inter-régions : 600€/mois
• Équipe DR dédiée (2 personnes) : 12 000€/mois
──────────────────────────────────────
TOTAL : ~16 300€/mois (~195 000€/an)
Exemple concret : E-commerce de taille moyenne
Scénario : Panne totale pendant 24 heures
PERTES DIRECTES :
• Chiffre d'affaires perdu : 50 000€/jour
• Clients perdus définitivement (10%) : 15 000€
• Frais de récupération d'urgence : 20 000€
──────────────────────────────────────
Sous-total : 85 000€
PERTES INDIRECTES :
• Atteinte à la réputation : 50 000€
• Temps équipe (crise + récupération) : 10 000€
• Pénalités contractuelles (SLA) : 25 000€
• Audit de sécurité post-incident : 15 000€
──────────────────────────────────────
Sous-total : 100 000€
═══════════════════════════════════════
TOTAL DES PERTES : 185 000€
═══════════════════════════════════════
Coût annuel d'un bon plan DR : 22 000€
ROI : Rentabilisé dès la première panne évitée
Conclusion : Ne PAS investir dans le DR coûte beaucoup plus cher que d'investir dedans.
Erreur : Penser que faire des backups = avoir un plan DR.
Réalité : Les backups ne sont qu'un élément du DR. Vous avez aussi besoin de :
- Procédures de restauration testées
- Monitoring
- Infrastructure de secours
- Équipe formée
- Documentation à jour
Vrai DR = Backups + Procédures + Tests + Formation
Erreur : Tester une seule fois et penser que c'est suffisant.
Réalité :
- Votre infrastructure évolue constamment
- PostgreSQL est upgradé
- L'équipe change
- Les procédures deviennent obsolètes
Solution : Tests réguliers (au moins trimestriels).
Erreur : Déléguer entièrement la responsabilité DR à un tiers.
Réalité :
- Leur backup peut échouer
- Leurs procédures de restauration peuvent être lentes
- Vous n'avez pas le contrôle
- Dépendance critique à un fournisseur
Solution : Toujours avoir vos propres backups en plus, même si l'hébergeur en fait.
Erreur : Penser que seules les grosses structures ont besoin de DR.
Réalité : Les PME sont plus vulnérables :
- Moins de ressources pour récupérer
- Impact proportionnellement plus important
- Moins de résilience financière
Les PME sont celles qui ont le PLUS besoin de DR.
Erreur : Croire que le cloud vous protège automatiquement.
Réalité :
- Le cloud protège contre les pannes matérielles
- Mais PAS contre : erreurs humaines, bugs logiciels, cyberattaques
- Responsabilité partagée : l'hébergeur gère l'infra, vous gérez vos données
Le cloud facilite le DR, mais ne le remplace pas.
Voici comment adapter votre stratégie DR selon votre contexte :
| Type d'application | Criticité | RTO suggéré | RPO suggéré | Stratégie DR |
|---|---|---|---|---|
| Blog personnel | Faible | 7 jours | 7 jours | Backup hebdomadaire S3 |
| Site vitrine PME | Moyenne | 24-48h | 24h | Backup quotidien + monitoring |
| Application SaaS B2B | Élevée | 2-4h | 1h | Backup + WAL archiving + standby |
| E-commerce | Critique | 30min-2h | 15min | Réplication synchrone + multi-AZ |
| Banque, Finance | Critique+ | 5-15min | 0-1min | Multi-région + HA automatisée |
| Systèmes médicaux | Critique+ | <5min | 0 | Réplication synchrone multi-site |
Le DR n'est pas qu'une question technique, c'est une culture :
-
Assumer que tout peut échouer
- Murphy's Law : "Tout ce qui peut mal tourner, va mal tourner"
- Ne jamais dire "ça ne peut pas arriver chez nous"
-
Tester, tester, tester
- Un plan non testé est un plan qui ne fonctionne pas
- Les tests révèlent les faiblesses avant qu'il ne soit trop tard
-
Documenter tout
- Les procédures doivent être claires pour n'importe qui
- Les runbooks doivent être à jour
-
Former l'équipe
- Tout le monde doit savoir quoi faire
- Exercices réguliers (fire drills)
-
Améliorer continuellement
- Chaque incident est une opportunité d'apprentissage
- Post-mortems blameless (sans blâmer les personnes)
-
Accepter le coût
- Le DR a un coût, c'est une assurance
- Mieux vaut payer pour ne pas l'utiliser que de ne pas l'avoir quand on en a besoin
Cette introduction au Disaster Recovery vous a présenté les concepts fondamentaux. Les sections suivantes vont approfondir chaque aspect :
19.5. Disaster Recovery (DR) ← Vous êtes ici
│
├─ 19.5.1. RTO et RPO : Définir les objectifs
│ └─ Comment déterminer vos objectifs de récupération
│
├─ 19.5.2. Tests de restauration réguliers
│ └─ Pourquoi, quand et comment tester vos procédures
│
└─ 19.5.3. Géo-réplication et Multi-Region
└─ Protéger contre les catastrophes régionales
Chaque section s'appuie sur la précédente :
- D'abord, vous définissez vos objectifs (RTO/RPO)
- Ensuite, vous mettez en place les procédures
- Puis, vous testez régulièrement
- Enfin, vous étendez géographiquement si nécessaire
Évaluez votre situation actuelle :
- Vous avez des backups automatisés
- Les backups sont testés régulièrement (au moins trimestriellement)
- Vous appliquez la règle 3-2-1
- Les backups sont stockés hors site (différent datacenter)
- Vous archivez les WAL pour Point-in-Time Recovery
- Vous savez combien de temps prend une restauration
- Vous avez documenté la procédure de restauration
- Vous avez au moins 1 serveur standby
- La réplication est monitorée
- Le lag de réplication est < 10 secondes
- Vous avez testé un failover manuel
- Vous connaissez le temps nécessaire pour un failover
- Vous êtes alerté si PostgreSQL tombe
- Vous êtes alerté si les backups échouent
- Vous êtes alerté si la réplication prend du retard
- Vous avez un système d'astreinte (on-call)
- Les alertes sont envoyées sur plusieurs canaux
- Vous avez des runbooks écrits pour chaque scénario
- Les runbooks sont à jour (< 6 mois)
- Toute l'équipe sait où trouver les runbooks
- Les contacts d'urgence sont documentés
- Les accès d'urgence sont documentés et testés
- Vous testez les restaurations au moins trimestriellement
- Toute l'équipe technique a été formée aux procédures DR
- Vous faites des post-mortems après chaque incident
- Vous avez fait au moins 1 disaster recovery drill complet
- Vous avez défini votre RTO (Recovery Time Objective)
- Vous avez défini votre RPO (Recovery Point Objective)
- Vos objectifs sont validés par la direction
- Vous respectez vos objectifs (mesuré lors des tests)
- Vous êtes conforme aux obligations légales (RGPD, etc.)
- 12-15 ✅ : Excellent ! Vous avez un bon plan DR
- 8-11 ✅ : Bien, mais des améliorations sont nécessaires
- 4-7 ✅ : Attention ! Votre organisation est à risque
- 0-3 ✅ : 🚨 Critique ! Vous êtes en danger, agissez immédiatement
Le Disaster Recovery n'est pas une option, c'est une nécessité absolue pour toute organisation qui dépend de ses données (donc, toutes les organisations).
Les questions que vous devez vous poser :
- Si notre base de données disparaît ce soir, que se passe-t-il demain matin ?
- Combien de données pouvons-nous nous permettre de perdre ?
- Combien de temps pouvons-nous rester hors ligne ?
- Notre équipe sait-elle exactement quoi faire en cas de crise ?
Si vous n'avez pas de réponses claires et rassurantes à ces questions, c'est maintenant qu'il faut agir.
Si vous n'avez pas encore de plan DR, commencez par ces 3 actions dès aujourd'hui :
-
📦 Mettez en place des backups automatisés
- Au minimum : backup quotidien vers S3 ou équivalent
- Testez une restauration cette semaine
-
📝 Documentez vos procédures
- Créez un runbook simple avec les étapes de restauration
- Notez les contacts d'urgence
-
⏰ Planifiez votre premier test
- Dans 2 semaines maximum
- Bloquez 2 heures dans votre calendrier
- Testez une restauration complète
Ne reportez pas. Le meilleur moment pour mettre en place un plan DR était il y a 1 an. Le deuxième meilleur moment, c'est maintenant.
Maintenant que vous comprenez l'importance du Disaster Recovery et ses composantes principales, la première étape concrète consiste à définir vos objectifs de récupération.
C'est exactement ce que nous allons voir dans la section suivante : 19.5.1. RTO et RPO : Définir les objectifs.
Vous y découvrirez comment calculer :
- Le temps d'indisponibilité maximum acceptable (RTO)
- La quantité de données que vous pouvez perdre (RPO)
- Comment ces objectifs influencent votre architecture technique
Passons à la suite ! →
Citation pour finir :
"Hope is not a strategy." — Proverbe DevOps
(L'espoir n'est pas une stratégie. Ayez un vrai plan DR.)