Tester une restauration après sinistre simulé

Une sauvegarde non restaurée est une hypothèse, pas une protection. Ce guide exécute un exercice de restauration après perte totale d’un serveur ou corruption tardive d’une base PostgreSQL, mesure le résultat, puis convertit chaque écart en correction traçable.

→ Lire l’explication complète de la marmotte

Objectifs RTO et RPO avant le test

Le RTO (Recovery Time Objective) est le délai maximal acceptable entre la déclaration d’un sinistre et le retour du service. Le RPO (Recovery Point Objective) est la quantité maximale de données que l’on accepte de perdre, exprimée en temps. Un RPO de quinze minutes signifie que la restauration doit retrouver un état vieux de quinze minutes au plus, pas « à peu près les dernières données ».

Le compromis central est brutal : réduire le RPO impose des sauvegardes plus fréquentes ou une journalisation continue, réduire le RTO impose une infrastructure de reprise préprovisionnée, des accès déjà validés et des procédures courtes. On paie du stockage, du réseau, des licences éventuelles et du temps d’exploitation. L’alternative est de payer pendant l’incident, avec une calculatrice beaucoup moins sympathique.

Fixer les objectifs avant de consulter les journaux du test. Sinon, tout retard devient miraculeusement acceptable une fois le café froid et le comité de crise réuni. Pour chaque service, inscrire au minimum :

Élément	Valeur cible	Règle de mesure
RTO applicatif	4 heures	Déclaration du sinistre jusqu’au contrôle fonctionnel validé
RPO base de données	15 minutes	Écart entre l’horodatage de reprise et le dernier état connu sain
Intégrité	100 % des contrôles	Schéma, contraintes, comptes, volumes et échantillon métier
Périmètre	Production simulée	Base, fichiers applicatifs, secrets de restauration et configuration

Ne pas confondre disponibilité et restaurabilité. Un cluster haute disponibilité peut masquer la perte d’un nœud, mais ne restaure ni une suppression répliquée ni une corruption logique. La réplication propage très efficacement les mauvaises écritures. C’est même son métier.

Les dépendances doivent être inventoriées avant le test : version majeure de PostgreSQL, extensions installées, format de sauvegarde, stockage objet, serveur de clés, certificats, résolveur de noms et règles réseau. Les pages données et réseaux servent de repères pour traiter ces dépendances comme un système, pas comme une collection de volumes.

Scénarios de sinistre à exécuter

Un test sérieux part d’un scénario qui peut réellement casser le service. « Restaurer une sauvegarde récente dans un conteneur vide » vérifie surtout que l’outil de sauvegarde sait lire ses propres fichiers. C’est nécessaire, mais largement insuffisant.

Scénario 1 : perte totale du serveur de production

Ce scénario suppose la destruction ou l’indisponibilité définitive de l’hôte : système, volumes locaux, configuration et cache perdus. La sauvegarde doit donc contenir, ou permettre de reconstruire, les éléments suivants :

La sauvegarde complète de la base et les journaux de transactions nécessaires.
La liste exacte des extensions PostgreSQL et leurs paquets système.
Les rôles, droits, paramètres serveur et tâches planifiées.
Les fichiers applicatifs persistants hors base, si le service en possède.
Les secrets permettant de lire le dépôt de sauvegarde et de déchiffrer les archives.
La procédure de reconstruction de l’hôte, versionnée avec l’infrastructure.

Une image de machine virtuelle réduit le temps de remise en route, mais ne dispense pas de restaurer les données. Elle réintroduit aussi des identifiants, des agents et parfois des clés privées dans un réseau isolé. Une image vieille de six mois n’est pas une machine neuve, c’est un musée avec accès administrateur.

Scénario 2 : corruption silencieuse détectée tardivement

Ce scénario est plus révélateur. Une erreur logique, un traitement applicatif défectueux ou un compte compromis modifie des données sans casser PostgreSQL. La corruption est découverte plusieurs heures plus tard. Restaurer la dernière sauvegarde complète peut alors restaurer exactement le problème.

La réponse est la restauration à un instant antérieur, souvent appelée restauration « point dans le temps ». Elle exige l’archivage continu des journaux de transactions et une rétention supérieure au délai de détection. Un RPO de quinze minutes ne protège rien si la corruption n’est détectée que trois jours après et que les journaux ne sont conservés qu’une journée.

Définir pour ce scénario :

l’instant estimé de début de corruption ;
l’instant de détection ;
le dernier événement métier connu sain ;
la fenêtre de journaux encore disponible ;
le niveau de preuve exigé pour autoriser la reprise.

La restauration doit viser le dernier état sain démontré, pas l’instant présumé. Une horloge applicative décalée de trois minutes peut suffire à réinjecter une suppression massive. Les horloges des serveurs doivent être synchronisées et les journaux conservés en temps universel coordonné, abrégé UTC (Coordinated Universal Time).

Préparer l’environnement isolé de restauration

L’environnement de test doit être séparé de la production par le réseau, les identifiants et la résolution de noms. Restaurer dans le même segment avec les mêmes certificats et le même nom de service ouvre la porte aux écritures accidentelles, aux appels de tâches planifiées et aux connexions applicatives non prévues. Le sinistre simulé n’a pas besoin d’un épisode bonus.

Créer un hôte ou une machine virtuelle dédiée, avec PostgreSQL de même version majeure que la source. PostgreSQL 16 restaure une sauvegarde physique PostgreSQL 16, pas une archive physique PostgreSQL 15. Les mises à niveau se font après validation de la restauration, jamais pendant l’exercice.

Prévoir avant le démarrage :

un volume local vide dimensionné pour la base restaurée, les journaux et 20 % de marge ;
un compte de lecture seule sur le dépôt de sauvegarde ;
une copie contrôlée des clés de déchiffrement ou un accès limité au gestionnaire de clés ;
une règle pare-feu refusant toute sortie vers les réseaux de production ;
des noms de service distincts, sans zone de recherche qui puisse résoudre un nom de production ;
des mécanismes de désactivation des envois de courriels, webhooks, paiements et traitements asynchrones.

Le dépôt de sauvegarde ne doit jamais être monté en écriture par l’environnement de test. Une restauration qui efface les archives source parce qu’un chemin a été inversé mérite un trophée, pas une seconde tentative. Utiliser une identité distincte, limitée à GetObject ou à son équivalent, et journaliser chaque lecture.

Les clés de déchiffrement restent un point de rupture majeur. Si une archive est chiffrée avec une clé de données protégée par une KEK (Key Encryption Key) conservée dans un HSM (Hardware Security Module) ou un gestionnaire de clés, le test doit valider l’autorisation de déchiffrement sans exposer la KEK. Un export de clé « juste pour le test » transforme une sauvegarde chiffrée en décor de conformité.

Exécuter la restauration PostgreSQL écrite

La procédure doit être écrite, stockée avec le code d’infrastructure et exécutée telle quelle. Une action mémorisée n’est pas une procédure, c’est une incantation dépendante d’une personne disponible et d’un cortex non saturé par l’incident.

L’exemple suivant restaure une sauvegarde physique PostgreSQL 16 dans /var/lib/postgresql/16/drill, puis cible un instant antérieur à une corruption. Il suppose que les journaux archivés ont été copiés en lecture seule dans /srv/dr-drill/wal et que la sauvegarde de base existe dans /srv/dr-drill/basebackup.

#!/usr/bin/env bash
# Exécuter sur l'hôte de test isolé avec PostgreSQL 16 installé.
# Ne jamais réutiliser le répertoire de données d'une instance active.
set -euo pipefail

export PGDATA=/var/lib/postgresql/16/drill
export RESTORE_TIME='2026-09-20 13:42:00+00'

sudo systemctl stop postgresql@16-main || true
sudo rm -rf "$PGDATA"
sudo install -d -o postgres -g postgres -m 0700 "$PGDATA"

# Extraire une sauvegarde créée avec pg_basebackup au format tar.
sudo -u postgres tar -xf /srv/dr-drill/basebackup/base.tar -C "$PGDATA"

# Demander à PostgreSQL de rejouer les journaux jusqu'à l'instant sain retenu.
sudo -u postgres touch "$PGDATA/recovery.signal"
sudo -u postgres tee -a "$PGDATA/postgresql.auto.conf" >/dev/null <<EOF
restore_command = 'cp /srv/dr-drill/wal/%f %p'
recovery_target_time = '${RESTORE_TIME}'
recovery_target_action = 'pause'
EOF

# Démarrer uniquement sur un port et une adresse réservés au réseau de test.
sudo -u postgres pg_ctl -D "$PGDATA" \
  -o "-p 55432 -c listen_addresses='127.0.0.1'" start

# Vérifier que la cible de récupération a été atteinte avant toute promotion.
sudo -u postgres psql -p 55432 -d postgres -c \
  "SELECT pg_is_in_recovery(), now();"

recovery_target_action = 'pause' impose un arrêt au point cible. C’est le bon choix lors d’un exercice de corruption : examiner les données avant de rendre la base inscriptible. Promouvoir trop tôt transforme une hypothèse de reprise en fait accompli, ce qui est une forme de courage assez coûteuse.

Après les contrôles, exécuter les tests définis dans le scénario : comptage des objets attendus, vérification de contraintes, lecture d’un échantillon métier et contrôle des extensions. Ne pas se limiter à pg_isready, qui confirme qu’un processus répond, pas que les données ont du sens.

Mesurer le résultat et corriger les écarts

Horodater les étapes en UTC : début de déclaration, accès au dépôt, fin de transfert, démarrage de PostgreSQL, fin du rejeu des journaux, validation fonctionnelle. Le RTO se mesure jusqu’à la validation fonctionnelle, pas jusqu’au moment où une console affiche un port ouvert.

Documenter le résultat dans une fiche d’exercice :

Mesure	Cible	Résultat	Écart	Action correctrice
RTO	4 h	5 h 12 min	+ 1 h 12 min	Préprovisionner l’hôte et automatiser l’installation des extensions
RPO	15 min	28 min	+ 13 min	Réduire l’intervalle d’archivage et surveiller le retard de dépôt
Journaux disponibles	72 h	49 h	- 23 h	Augmenter la rétention immuable du dépôt
Contrôles métier	100 %	98 %	2 %	Ajouter un contrôle de cohérence avant sauvegarde

Chaque écart devient une tâche avec un propriétaire, une échéance et un test de vérification. « Restauration lente » n’est pas une action. « Augmenter le débit minimal du lien de reprise à 500 Mbit/s et rejouer le scénario » en est une.

La supervision doit alerter sur l’âge de la dernière sauvegarde, l’âge du dernier journal archivé, les erreurs de chiffrement, la capacité restante, l’échec des copies hors site et l’absence de test de restauration récent. Une sauvegarde verte sur un tableau de bord ne garantit que l’absence d’alerte connue. Les tableaux de bord ont une confiance en eux que les données ne méritent pas toujours.

La rotation des secrets de dépôt et des clés de chiffrement doit être testée avec des archives anciennes. Une nouvelle clé protège les futures sauvegardes ; elle ne ressuscite pas une clé supprimée qui protège les anciennes. Conserver les versions nécessaires pendant toute la durée de rétention, avec sauvegarde des métadonnées de chiffrement et procédure de reprise du gestionnaire de clés. Les principes de cryptographie appliquée s’appliquent ici sans exception : perdre la clé revient à perdre les données.

🐝 Ce qui arrive si on s’en passe

Sans exercice de restauration, les objectifs RTO et RPO restent déclaratifs : rien ne permet de prouver un délai de reprise ni une perte maximale de données devant un auditeur, un assureur ou un client contractuellement engagé. Les dépendances muettes ne se révèlent qu’en incident réel : paquet d’extension absent du dépôt de la distribution, version majeure de PostgreSQL non disponible, clé de chiffrement d’archive retirée lors d’une rotation, identifiant de dépôt expiré. L’absence de répétition laisse aussi les droits d’accès au dépôt non vérifiés, donc potentiellement en écriture, ce qui expose les archives à un effacement pendant la tentative de reprise. Enfin, aucune mesure horodatée n’existe pour arbitrer entre restauration partielle et attente, et les décisions se prennent sous pression, sans point de comparaison ni trace exploitable après coup.

🦫 Explication de la marmotte 🍫

Un test de restauration vérifie qu’un service peut repartir après une panne grave. Avant le test, on choisit un problème réaliste : perdre entièrement le serveur, ou découvrir que des données ont été abîmées depuis plusieurs heures. On fixe ensuite deux limites : le temps maximal acceptable avant le retour du service, et la quantité maximale de données perdables.

Le test se déroule sur une machine séparée. Cette séparation empêche les données restaurées, les programmes automatiques ou les comptes techniques de toucher le vrai service. On utilise une procédure écrite, car une procédure de mémoire change selon le stress, la fatigue et la personne présente.

Pour une base de données, on remet d’abord une copie complète. Puis on rejoue les enregistrements qui décrivent les modifications effectuées après cette copie. Si une corruption a été détectée, on arrête ce rejeu juste avant le moment où les données ont commencé à devenir fausses. On vérifie alors que la base démarre, que les données attendues existent, que les droits sont présents et que les fonctions du service répondent.

Enfin, on compare le temps réellement pris et les données récupérées avec les limites décidées au départ. Si le test est trop lent, si des données manquent ou si une clé manque pour déchiffrer les archives, le test échoue. Chaque échec doit modifier la procédure, le stockage, les accès ou la surveillance, puis être testé à nouveau.

Pages voisines

La citent

Tester une restauration après sinistre simulé

Elle cite

: les deux pages se citent l’une l’autre.

Tester une restauration après sinistre simulé

Tester une restauration après sinistre simulé

Objectifs RTO et RPO avant le test

Scénarios de sinistre à exécuter

Scénario 1 : perte totale du serveur de production

Scénario 2 : corruption silencieuse détectée tardivement

Préparer l’environnement isolé de restauration

Exécuter la restauration PostgreSQL écrite

Mesurer le résultat et corriger les écarts

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines