🔝 Retour au Sommaire
Dans le monde de la gestion des bases de données et du Disaster Recovery (récupération après sinistre), deux acronymes reviennent constamment : RTO et RPO. Ces concepts sont fondamentaux pour définir votre stratégie de sauvegarde et de récupération, et comprendre leur signification est essentiel pour tout professionnel travaillant avec PostgreSQL.
Imaginez que votre base de données tombe en panne suite à une défaillance matérielle, une erreur humaine, ou un sinistre (incendie, inondation, cyberattaque). Deux questions cruciales se posent immédiatement :
- Combien de temps pouvez-vous vous permettre d'être hors ligne ?
- Quelle quantité de données pouvez-vous accepter de perdre ?
C'est exactement ce que RTO et RPO vous aident à quantifier.
Le RTO (Recovery Time Objective) est le temps maximum acceptable pendant lequel votre système peut être indisponible après un incident. C'est la durée maximale de l'interruption de service que votre organisation peut tolérer.
En d'autres termes : Combien de temps pouvez-vous rester « hors ligne » ?
Prenons l'exemple d'une boutique e-commerce :
- RTO de 4 heures : Votre site peut être indisponible pendant maximum 4 heures. Au-delà, les pertes financières et l'impact sur la réputation deviennent inacceptables.
- RTO de 15 minutes : Pour une plateforme bancaire en ligne, 15 minutes d'indisponibilité peuvent déjà causer des pertes importantes.
- RTO de 30 secondes : Pour un système de trading haute fréquence, même 30 secondes peuvent représenter des millions d'euros de pertes.
Le RTO inclut plusieurs phases :
- Détection de l'incident : Temps pour identifier qu'un problème existe
- Diagnostic : Temps pour comprendre la nature du problème
- Décision : Temps pour décider de la stratégie de récupération
- Restauration : Temps effectif pour restaurer le service
- Validation : Temps pour vérifier que tout fonctionne correctement
Exemple de calcul :
Détection : 5 minutes
Diagnostic : 10 minutes
Décision : 5 minutes
Restauration : 30 minutes
Validation : 10 minutes
─────────────────────────────
RTO Total : 60 minutes (1 heure)
Le RPO (Recovery Point Objective) est la quantité maximale de données que votre organisation peut accepter de perdre, mesurée en temps. Il représente l'âge maximal acceptable de vos données après une restauration.
En d'autres termes : Jusqu'où pouvez-vous « remonter dans le temps » en perdant des données ?
Continuons avec notre boutique e-commerce :
- RPO de 24 heures : Vous pouvez accepter de perdre les transactions des dernières 24 heures. Si l'incident survient à 14h le mardi, vous restaurez les données de lundi 14h.
- RPO de 1 heure : Vous ne pouvez perdre qu'une heure de données maximum.
- RPO de 0 (zéro) : Aucune perte de données n'est acceptable. Chaque transaction doit être préservée (réplication synchrone).
Dernière sauvegarde Incident
↓ ↓
──────────────●──────────────────────────●──────────→ Temps
│◄────── RPO ──────────────►│
│ │
Données OK Données perdues
Les données entre la dernière sauvegarde et l'incident sont potentiellement perdues. Le RPO définit cette fenêtre de risque acceptable.
| Aspect | RTO | RPO |
|---|---|---|
| Question | Combien de temps d'indisponibilité ? | Combien de données perdues ? |
| Mesure | Durée (minutes, heures) | Période temporelle (minutes, heures) |
| Impact sur | Disponibilité du service | Intégrité des données |
| Coût principal | Infrastructure de récupération rapide | Fréquence et type de sauvegardes |
| Exemple | "Le site doit être en ligne en 2h" | "On peut perdre max 30 min de transactions" |
INCIDENT SURVIENT
↓
│
│ ◄─── RPO : Données perdues (ex: 1 heure)
│ (entre dernière sauvegarde et incident)
↓
RESTAURATION COMMENCE
│
│ ◄─── RTO : Temps d'indisponibilité (ex: 4 heures)
│ (temps pour remettre le système en ligne)
↓
SERVICE RESTAURÉ
Posez-vous les questions suivantes :
- Quel est le coût de l'indisponibilité par heure ?
- Quel est l'impact sur la réputation ?
- Existe-t-il des obligations légales ou contractuelles (SLA) ?
- Quelles sont les conséquences pour les utilisateurs ?
- Quel est le volume de transactions par heure ?
- Quelle est la valeur des données générées ?
- Peut-on reconstituer les données perdues manuellement ?
- Existe-t-il des obligations de conformité (RGPD, finance) ?
Créez un tableau d'analyse par criticité :
| Type de système | RTO suggéré | RPO suggéré | Justification |
|---|---|---|---|
| Site vitrine | 24-48h | 24h | Impact faible, contenu statique |
| Blog/CMS | 4-8h | 4-12h | Impact modéré, perte de commentaires acceptable |
| E-commerce | 1-4h | 15min-1h | Perte de revenus directe |
| Banque en ligne | 15min-1h | 0-5min | Obligations réglementaires strictes |
| Système de paiement | 5-15min | 0 (temps réel) | Transactions financières critiques |
| Application interne | 8-24h | 8-24h | Impact limité aux employés |
Plus vos objectifs sont ambitieux (RTO et RPO faibles), plus l'infrastructure nécessaire est coûteuse.
RPO : 24h → 4h → 1h → 15min → 5min → 0 (temps réel)
│ │ │ │ │ │
│ │ │ │ │ └─ Réplication synchrone
│ │ │ │ └──────── Streaming replication + WAL archiving
│ │ │ └──────────────── Sauvegardes fréquentes + PITR
│ │ └─────────────────────── Sauvegardes régulières
│ └───────────────────────────── Sauvegarde quotidienne
└───────────────────────────────────── Sauvegarde hebdomadaire
Coût : Faible ────────────────────────→ Très élevé
Cas d'usage : Site e-commerce de taille moyenne
Analyse métier :
- Chiffre d'affaires : 500 000€/mois (environ 20 000€/jour)
- Pic d'activité : 14h-18h (40% du CA quotidien)
- Moyenne : 100 commandes/heure
- Valeur moyenne commande : 50€
Calcul de l'impact :
- Indisponibilité de 1h en heures creuses : ~800€ de perte
- Indisponibilité de 1h en heures pleines : ~3 300€ de perte
- Perte de données de 1h : ~100 commandes × 50€ = 5 000€
Objectifs définis :
- RTO : 2 heures (compromis entre coût et impact)
- RPO : 15 minutes (limite les pertes de commandes)
Solution technique correspondante :
- Streaming replication asynchrone (standby serveur)
- Sauvegardes continues avec archivage WAL
- Point-In-Time Recovery (PITR) activé
- Monitoring et alerting automatiques
Vous aurez besoin de :
- WAL Archiving continu : Archive des Write-Ahead Logs en temps quasi-réel
- Point-In-Time Recovery (PITR) : Capacité à restaurer à n'importe quel point dans le temps
- Réplication asynchrone ou synchrone : Serveur standby maintenu à jour
Configuration PostgreSQL :
-- Dans postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'cp %p /archive/%f'
max_wal_senders = 3 Vous aurez besoin de :
- Réplication synchrone (Streaming Replication) : Les transactions ne sont validées que lorsque confirmées sur le standby
- Monitoring en temps réel : Détection immédiate des problèmes
- Failover automatisé : Basculement rapide avec Patroni ou repmgr
Configuration PostgreSQL :
-- Dans postgresql.conf
synchronous_commit = on
synchronous_standby_names = 'standby1' Vous aurez besoin de :
- Infrastructure de haute disponibilité : Serveur standby prêt à l'emploi (hot standby)
- Procédures de failover testées : Scripts et runbooks documentés
- Monitoring et alerting : Détection rapide des incidents
- Équipe d'astreinte : Personnel disponible 24/7
Vous aurez besoin de :
- Failover automatique : Patroni avec etcd/Consul pour consensus distribué
- Load balancer : Redirection automatique du trafic (HAProxy, PgBouncer)
- Health checks automatisés : Détection et réaction en secondes
- Infrastructure cloud ou multi-région : Résilience géographique
Contexte : Application SaaS B2B, 500 clients, équipe de 3 développeurs
Objectifs :
- RTO : 4 heures (acceptable pour une petite structure)
- RPO : 1 heure (perte limitée de données)
Solution :
- Sauvegardes automatiques quotidiennes (pg_dump)
- WAL archiving toutes les 15 minutes
- Serveur de backup sur cloud (AWS S3)
- Procédure de restauration documentée et testée mensuellement
Coût mensuel estimé : ~200€ (stockage + compute)
Contexte : 50 000 commandes/jour, équipe DevOps de 5 personnes
Objectifs :
- RTO : 30 minutes (obligation SLA clients)
- RPO : 5 minutes (minimiser les pertes de commandes)
Solution :
- Réplication synchrone avec 1 standby hot
- WAL archiving continu vers S3
- Patroni + etcd pour failover automatique
- Monitoring (Prometheus + Grafana)
- Tests de DR trimestriels
Coût mensuel estimé : ~2 000€ (infrastructure HA)
Contexte : Banque en ligne, millions de transactions/jour, obligations réglementaires
Objectifs :
- RTO : 5 minutes (criticité maximale)
- RPO : 0 (zéro perte de données)
Solution :
- Réplication synchrone avec quorum (2+ standbys)
- Multi-région (géo-réplication)
- Patroni avec consensus distribué (etcd cluster)
- Backup continu avec validation d'intégrité
- Infrastructure redondante (N+2)
- Tests de DR mensuels obligatoires
- Équipe d'astreinte 24/7
Coût mensuel estimé : ~50 000€+ (infrastructure enterprise)
Erreur : "Notre RPO doit être zéro et notre RTO de 5 minutes" sans avoir l'infrastructure ni le budget correspondant.
Solution : Soyez réaliste et alignez vos objectifs avec vos ressources.
Erreur : Avoir une stratégie de backup parfaite sur le papier, mais découvrir qu'elle ne fonctionne pas lors d'un incident réel.
Solution : Testez régulièrement vos restaurations (au moins trimestriellement).
# Exemple de test de restauration planifié
# À exécuter sur environnement de test
# 1. Créer une sauvegarde
pg_basebackup -D /backup/test -F tar -z -P
# 2. Simuler une perte
# (sur serveur de test uniquement !)
# 3. Restaurer
tar -xzf /backup/test/base.tar.gz -C /var/lib/postgresql/data
# 4. Vérifier l'intégrité
psql -c "SELECT count(*) FROM critical_table;"
# 5. Mesurer le temps total
# RTO réel = temps de détection + restauration + validationErreur : Seul le DBA senior connaît la procédure de récupération.
Solution : Documentez tout dans un runbook accessible 24/7.
Contenu minimum d'un runbook DR :
- Diagramme de l'architecture
- Procédure step-by-step de restauration
- Commandes exactes à exécuter
- Contacts d'urgence (on-call)
- Checklist de validation
- Post-mortem template
Erreur : Vos sauvegardes sont stockées uniquement sur le même datacenter que votre production.
Solution : Appliquez la règle 3-2-1 :
- 3 copies de vos données
- Sur 2 types de supports différents
- Dont 1 copie hors site (off-site)
Exemple PostgreSQL :
Production DB (Primary)
↓
├─→ Standby local (Streaming replication)
├─→ WAL Archive S3 (même région)
└─→ Backup S3 (région différente) ← Off-site
Utilisez cette checklist pour structurer votre réflexion :
- J'ai calculé le coût de l'indisponibilité par heure
- J'ai identifié les heures critiques (pics d'activité)
- J'ai évalué l'impact sur les utilisateurs/clients
- J'ai vérifié les obligations légales/SLA
- J'ai consulté les parties prenantes (direction, métier)
- RTO défini et documenté
- RPO défini et documenté
- Objectifs validés par la direction
- Budget alloué pour l'infrastructure nécessaire
- Solution technique choisie (réplication, backup, etc.)
- Procédures de restauration documentées
- Tests de restauration planifiés
- Monitoring et alerting configurés
- Équipe formée aux procédures DR
- Tests de restauration réguliers (au moins trimestriels)
- Métriques RTO/RPO réels mesurées
- Documentation à jour
- Post-mortems après chaque incident
- Révision annuelle des objectifs
Le RTO et le RPO ne sont pas de simples acronymes techniques : ce sont des décisions business critiques qui doivent être prises en collaboration entre l'équipe technique, le métier et la direction.
Points clés à retenir :
- RTO = Temps d'indisponibilité acceptable → Impact sur la disponibilité
- RPO = Perte de données acceptable → Impact sur l'intégrité
- Plus vos objectifs sont ambitieux, plus le coût est élevé
- Il n'existe pas de "bon" RTO/RPO universel, uniquement ce qui correspond à votre contexte
- Testez, testez, testez vos procédures de restauration !
Prochaine étape : Une fois vos objectifs définis, vous devez mettre en place l'infrastructure technique correspondante (réplication, backup, monitoring) pour les atteindre réellement. C'est ce que nous verrons dans les sections suivantes du chapitre sur le Disaster Recovery.
- Documentation PostgreSQL : High Availability, Load Balancing, and Replication
- Documentation PostgreSQL : Backup and Restore
- Article : "The Cost of Downtime" (Gartner, 2023)
- Livre recommandé : PostgreSQL High Availability Cookbook par Shaun Thomas