Reprise après sinistre : runbooks, tests de basculement et communication

La reprise après sinistre n’est pas une mesure isolée, mais une chaîne de décisions, de dépendances et de gestes répétés et maîtrisés. En pratique, les remises en service échouent rarement parce qu’« aucune sauvegarde n’existe ». Plus souvent, les Runbooks sont incomplets, les responsabilités floues, les chemins de basculement jamais testés en conditions réelles ou la communication crée une pression inutile et de mauvaises priorités.

Ce billet s’adresse aux administrateurs, ingénieurs systèmes, opérateurs et pRESTataires IT techniques. L’accent est mis sur une démarche pragmatique : comment rédiger des Runbooks qui tiennent en situation de stress, planifier des tests de basculement sans mettre en danger la production, et organiser la communication et les processus décisionnels pour que les équipes techniques RESTent opérationnelles. Les exemples se fondent sur des configurations MariaDB typiques (réplication, sauvegardes, Point-in-Time-Recovery), mais intègrent délibérément aussi des sujets d’infrastructure comme DNS, équilibreurs de charge, gestion des identités et supervision.

Reprise après sinistre en pratique

Un « désastre » est, sur le plan opérationnel, moins un événement isolé qu’un état : un service est indisponible, la cause n’est pas immédiatement évidente et la chaîne normale de modifications et d’approbations est trop lente. Les déclencheurs typiques sont les rançongiciels (y compris les comptes administrateur compromis), une panne de stockage, des erreurs lors de mises à jour, un incident cloud/fournisseur, des problèmes de segment réseau ou une corruption logique des données (p. ex. une application défaillante écrit des données incorrectes).

Les Runbooks échouent souvent pour les mêmes raisons :

• Hypothèses erronées : « L’hôte de monitoring fonctionne », « DNS est disponible », « nous avons une connexion Internet », « les sauvegardes sont lisibles ».
• Étapes trop vagues : « RESTore DB » sans précision sur la version, le mode de récupération, la validation, les dépendances et le point de retour.
• Pas de points de décision : Les Runbooks ont besoin de règles « si… alors… » claires (p. ex. corruption des données vs. panne d’infrastructure).
• Communication non préparée : L’équipe technique est submergée de demandes d’état, alors que des décisions (p. ex. accepter la perte de données ?) ne sont pas prises.

Le remède est une combinaison de (1) Runbooks bien structurés, (2) tests réalistes, (3) répartition claire des rôles et (4) règles de communication qui soutiennent la reprise technique au lieu de la bloquer.

RTO et RPO : définir les objectifs avant de rédiger un Runbook

Sans valeurs cibles, tout Runbook sera soit trop conservateur (trop lent), soit trop risqué (trop de perte de données). Deux notions sont centrales :

• RTO (Recovery Time Objective) : délai cible jusqu’à ce que le service soit à nouveau utilisable. Concrètement : quand les utilisateurs peuvent-ils reprendre leur travail, pas quand tout est « parfait ».
• RPO (Recovery Point Objective) : perte de données maximale tolérable mesurée en temps. Concrètement : « au pire cas, nous ne pouvons revenir que jusqu’à 15 minutes en arrière ».

Pour MariaDB, cela signifie souvent : le RTO est limité par la durée du RESTore, la bascule DNS/load-balancer, l’invalidation du cache applicatif et la compatibilité des schémas. Le RPO dépend du retard de réplication, des intervalles de sauvegarde et du Point-in-Time-Recovery (PITR, RESTauration jusqu’à un instant donné à partir des binlogs).

Important : consignez le RTO/RPO par service, pas « pour la base de données ». Une base de données peut fonctionner techniquement tandis que le logiciel métier RESTe indisponible à cause de secrets manquants, d’endpoints erronés ou de jobs cassés.

Conception du runbook : structure, rôles et règles « Stop-the-Line »

Un runbook est un manuel d’exploitation pour la gestion des incidents. Il doit être lisible en 2–3 minutes et néanmoins suffisamment profond pour étayer les décisions et les actions. La structure suivante a fait ses preuves :

1) En-tête : objectif, périmètre, prérequis

• Objectif : « Redémarrage du service MariaDB X après perte totale du centre de données primaire ».
• Périmètre : Quels systèmes sont inclus (DB, proxy/load balancer, DNS, monitoring, stockage de sauvegarde, secrets) ?
• Prérequis : accès (comptes break-glass), copies hors-ligne, clés/mots de passe, réseau d’urgence.

2) Modèle de rôles : qui décide, qui exécute

En cas de désastre, la parallélisme est critique. Définissez au minimum :

• Incident Lead : coordonne, priorise, protège l’équipe des changements de contexte.
• DB Operator : exécute les étapes MariaDB, documente les horaires et les constats.
• Infra Operator : DNS, load balancer, stockage, réseau, VM/container, chemins d’accès.
• Communication : mises à jour de statut, parties prenantes, éventuels tickets fournisseur.

Les règles « Stop-the-Line » doivent figurer explicitement dans le runbook : dans quelles situations on s’arrête immédiatement (p. ex. suspicion d’une ransomware en cours, intégrité des données incertaine, lacunes inexpliquées des binlogs) ? Cela évite un redémarrage frénétique dans un environnement encore compromis.

3) Arbre de décision : basculer ou RESTaurer ?

Les runbooks doivent lister non seulement des étapes, mais des chemins. Question centrale : Failover (basculement vers une standby existante) ou RESTore (RESTauration depuis des sauvegardes) ? Le failover est généralement plus rapide (RTO), le RESTore peut être plus sûr (sécurité/intégrité) – notamment après une ransomware ou une corruption logique.

Principes techniques pour la DR de MariaDB : réplication, sauvegardes, PITR

En exploitation d’entreprise, trois briques sont typiques pour MariaDB :

• Réplication : les systèmes secondaires reçoivent les changements depuis la primaire. Selon le déploiement, elle est asynchrone ou semi-synchrone. Risque : la réplication transporte aussi les changements indésirables (corruption, suppressions).
• Sauvegardes physiques/logiques : les sauvegardes physiques (niveau fichier, p. ex. procédures compatibles Percona XtraBackup) sont généralement plus rapides au RESTore ; les sauvegardes logiques (mysqldump) sont plus portables mais lentes sur de gros volumes.
• PITR (Point-in-Time-Recovery) : RESTauration jusqu’à un instant situé entre une sauvegarde et « maintenant » à l’aide des binlogs (journaux binaires de modifications). Condition : les binlogs sont complets, horodatés et accessibles.

Un runbook DR doit préciser concrètement quelle combinaison vous employez : « Failover vers la replica A » n’est pas la même chose que « RESTore du dernier backup complet + binlogs jusqu’à T-15min ». Et : pour MariaDB, la vérification d’intégrité (p. ex. contrôle des tables, vérifications d’intégrité applicative) après redémarrage est souvent le goulot d’étranglement, pas la copie des données.

Préparation : éléments à documenter et à fournir avant un sinistre

De nombreux sinistres échouent sur le plan opérationnel parce que des « petits éléments » manquent. Cette checklist est délibérément pragmatique et rédigée du point de vue de l’exploitation :

Identités et accès (Break Glass)

„Break Glass“ désigne des accès d’urgence gérés séparément des comptes admin normaux et particulièrement protégés (p. ex. MFA-Token stockés hors ligne, identifiants scellés, politiques de mot de passe séparées). Pour DR important :

• Accès SSH/RDP d’urgence vers un réseau admin isolé
• Accès DB-Admin qui ne dépend pas de SSO/IdP (IdP = Identity Provider, authentification centralisée)
• Accès au repository de sauvegardes et au matériel de clés (chiffrement, Object-Storage-Keys)

Inventaire des configurations et dépendances

Au minimum : versions (MariaDB, OS, Proxy), paramètres (innodb_flush_log_at_trx_commit, binlog_format), topologie (Primary/Replica, GTID oui/non), noms DNS, ports, règles de pare-feu, classes de stockage, Monitoring-Checks, Cronjobs/Batch-Jobs. Sans cela, toute remise en service se transforme en reconstruction improvisée.

Voie hors ligne et « sans Internet »

Préparez le scénario où ni Internet ni la console cloud ne sont accessibles. Ça paraît extrême, mais c’est réaliste en cas d’incidents chez le provider, de problèmes BGP ou d’incidents de sécurité. Mesures pratiques :

• Copie hors ligne des Runbooks (PDF/imprimé) et des secrets les plus importants (sécurisée)
• Repo/cache local pour paquets ou images de conteneurs (sinon la reconstruction échoue faute de téléchargement)
• Accès out-of-band (p. ex. iLO/iDRAC/IPMI ou accès console série) sur un réseau séparé

Tests de basculement : types, risques et critères de réussite

Les tests de basculement ne sont pas un « événement », mais un processus répétable. Il est essentiel de définir des critères de réussite qui vont au-delà d’un simple « ping OK ». Pour MariaDB et les services dépendants, les tests doivent couvrir au minimum : accès en écriture/lecture, consistance des transactions, authentification applicative, jobs/queues critiques, reporting, ainsi que Monitoring/Alerting.

Types de tests (du sûr au réaliste)

• Tabletop/Walkthrough : L’équipe passe en revue le Runbook sans modifier les systèmes. Utile pour les rôles et la communication, faible pour les détails techniques.
• Failover simulé en test/staging : techniquement utile, mais souvent avec des volumes de données et profils de charge différents.
• Basculement planifié en production : fort gain d’enseignements, mais doit être soigneusement préparé (fenêtre de maintenance, rollback, parties prenantes).
• Exercice de basculement non planifié : approche « chaos » avec éléments de surprise. Réservé aux équipes matures et à une automatisation stable.

Pièges typiques lors d’un basculement MariaDB

• Replica lag : le retard de réplication entraîne un RPO plus élevé que prévu. Causes fréquentes : goulots d’I/O ou transactions volumineuses.
• Séparation lecture/écriture : les applications ou proxys (p. ex. ProxySQL) utilisent des points de terminaison distincts ; après un failover, ils continuent d’écrire sur le « read-only » ou dans la mauvaise direction.
• DNS-TTL : une TTL (Time To Live, durée de cache) trop longue retarde la bascule. Une TTL trop courte augmente la charge et la probabilité d’erreurs.
• GTID/Position-Drift : si la topologie et la position de réplication ne sont pas correctement documentées, un split-brain (deux systèmes primaires) peut survenir.
• Régression de sécurité : les modifications d’urgence contournent le durcissement (pare-feu « brièvement ouvert », droits utilisateurs mal définis).

Test de failover minimal (concret, en 60–120 minutes)

Si vous disposez de fenêtres de maintenance limitées, priorisez un test qui apporte le maximum d’information :

1. Gel des modifications : arrêter les deployments, mettre en pause les jobs batch, réduire la charge d’écriture.
2. Vérifier l’état des répliques : s’assurer que la réplication a rattrapé son retard (catch up), documenter le lag.
3. Basculement : pointer le point de terminaison applicatif vers la réplique, mettre le primaire en read-only ou l’isoler.
4. Contrôles de cohérence : connexion, test lecture/écriture, rapports/jobs les plus importants.
5. Rollback : basculer en arrière ou conserver le nouveau primaire, mais décider clairement.
6. Travaux de suivi : créer des tickets pour les lacunes identifiées, mettre à jour le runbook, enregistrer les durées.

Runbook de RESTauration pour MariaDB : séquence d’étapes, vérifications, stratégie de repli

La RESTauration est la voie « dure », car elle comporte davantage d’inconnues : cohérence des backups, clés, performances lors de la RESTauration, et surtout validation. Un bon runbook de RESTauration sépare strictement : RESTauration (remettre les données) et remise en service (rendre le service utilisable).

Phase 1 : clarifier la situation et définir l’état cible

• Classe d’incident : défaut d’infrastructure, corruption de données, incident de sécurité (p. ex. ransomware) ?
• Point cible : « dernier backup cohérent » ou PITR jusqu’au point T ?
• Décision de risque : compromis RPO (perte de données) vs RTO (temps). Cette décision doit être délibérée et documentée.

Particulièrement en cas de corruption logique, le basculement sur une réplique est dangereux car les mauvaises modifications ont été répliquées. Dans ce cas, la RESTauration/PITR est généralement le chemin sûr.

Phase 2 : provisionner l’infrastructure (sans raccourcis)

La RESTauration échoue souvent sur des éléments apparemment simples : versions de paquets incorrectes, paramètres du noyau manquants, options de système de fichiers différentes, volumes trop petits, ou paramètres InnoDB incompatibles. Consignez dans le runbook :

• Forme cible : VM, bare metal, conteneur (et quelle classe de stockage)
• Capacité : données + espace supplémentaire pour la RESTauration (souvent sensiblement plus temporairement)
• Réseau : segment, pare-feu, n’ouvrir que les ports nécessaires
• Synchronisation temporelle : NTP/Chrony (important pour les logs, la référence temporelle des binlogs, les audits)

Phase 3 : retrouver la sauvegarde, la vérifier, la rendre RESTaurable

La vérification est obligatoire. « Sauvegarde présente » n’est pas une preuve de « sauvegarde lisible ». Vérifiez au minimum : existence, taille/tendance, sommes de contrôle, clés de chiffrement, droits d’accès et si la sauvegarde a été créée de manière cohérente.

Exemple : une étape de contrôle simple, indépendante du dépôt, pour des fichiers d’archive (intégrité et décompressibilité) peut ressembler à :

#!/usr/bin/env bash
set -euo pipefail

BACKUP_TAR="/mnt/backup/mariadb-full-2026-07-28.tar.gz"
SHA_FILE="${BACKUP_TAR}.sha256"

# 1) Prüfsumme verifizieren
sha256sum -c "$SHA_FILE"

# 2) Archiv testweise lesen (ohne zu extrahieren)
tar -tzf "$BACKUP_TAR" > /dev/null

echo "Backup-Archiv ist lesbar und Prüfsumme passt."

Pourquoi cela fonctionne : les sommes de contrôle couvrent les erreurs silencieuses au niveau des bits ; la liste de test de l’archive tar détecte les compressions ou structures de conteneur défectueuses. Quand cela échoue : si la sauvegarde est intègre en tant que fichier mais incohérente en contenu (p. ex. pas de snapshot propre, tablespaces manquants, binlogs incomplets). Il faut donc en complément une validation proche de la base de données (voir ci‑dessous).

Phase 4 : effectuer la RESTauration (physique/logique) puis valider

La méthode de RESTauration concrète dépend de votre procédure de sauvegarde. Pour le runbook, les points de contrôle universels sont :

• Démarrer la DB dans un état contrôlé : ne laisser aucune application s’y connecter, n’autoriser les écritures qu’après succès de la validation.
• Phase en lecture seule : d’abord lecture/contrôle uniquement, puis autoriser la charge en écriture.
• Vérifications schéma/migrations : le schéma correspond-il à la version de l’application ? Sinon, des erreurs secondaires sont à prévoir.

Un bloc SQL pratique pour des vérifications de plausibilité rapides (sans plonger dans les internals du moteur) :

-- Verbindung und Grundzustand
SELECT VERSION() AS mariadb_version;
SHOW VARIABLES LIKE 'read_only';
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';

-- Replikations-/Binlog-Relevanz (falls genutzt)
SHOW VARIABLES LIKE 'log_bin';
SHOW BINARY LOGS;

-- Grobe Konsistenzsignale: Tabellenstatus und Fehler
SHOW DATABASES;
-- Für ausgewählte Kern-Tabellen (Beispielnamen anpassen):
CHECK TABLE app.core_customer;
CHECK TABLE app.core_order;

Pourquoi c’est utile : vous vérifiez que vous êtes sur la version attendue, que le serveur n’est pas accidentellement inscriptible, que des binlogs sont présents (pertinent pour le PITR et la réplication ultérieure) et que les tables centrales semblent au moins superficiellement cohérentes. Limites : CHECK TABLE n’est pas une panacée, et InnoDB peut ne révéler certains problèmes qu’en charge. Complétez donc par des checks de sanity applicatifs (connexion, processus core, rapports critiques).

Phase 5 : effectuer correctement le PITR (Point-in-Time-Recovery)

PITR signifie : vous RESTaurez une sauvegarde complète puis appliquez des binlogs jusqu’à un instant défini. Pour que cela fonctionne, les binlogs doivent être complets et datés de manière univoque. Pièges typiques :

• Fuseaux horaires / dérive d’horloge : le décalage temporel complique la décision du « stop-date-time ».
• Lacunes dans les binlogs : fichiers manquants dus à la rétention, à des erreurs de stockage ou à un offloading incorrect.
• Objectif temporel imprécis : le métier dit « avant l’incident », mais le moment exact de l’incident n’est pas correctement corrélé (consultez les logs !).

Dans le runbook, vous devriez donc prévoir : (1) une chronologie extraite des monitoring/applika­tionslogs, (2) une définition claire du « dernier bon commit », (3) une séquence de commandes documentée correspondant à votre tooling. Si vous utilisez mysqlbinlog, testez la procédure régulièrement dans un environnement isolé, car de petits paramètres erronés (p. ex. mauvaise interprétation des GTID) ne se remarquent souvent qu’en situation réelle.

Phase 6 : Rückfallstrategie (Rollback) für den RESTore selbst

Une RESTauration peut échouer : backup finalement corrompu, clé erronée, le RESTore prend plus de temps que le RTO, ou la validation échoue. Prévoyez donc le Rückfall non pas comme « on continue d’essayer », mais comme une option définie :

• Plan B Failover : si le RESTore prend trop de temps, basculer sur une Replica avec une perte de données acceptée.
• Plan C Minimalbetrieb : mode lecture seule pour les fonctions centrales (p. ex. Reporting) avec communication claire.
• Forensik-Pfad : en cas d’incident de sécurité : isoler les systèmes, pas d’« Aufräumaktionen » sans autorisation.

Kommunikation im Desaster-Fall: Takt, Inhalte, Entscheidungslog

La communication est, en situation d’urgence, un facteur technique car elle détermine le focus et le débit. Un schéma éprouvé est un rythme de mises à jour fixe (p. ex. toutes les 15–30 minutes) et un format de statut uniforme. Cela réduit les demandes de clarification et évite des déclarations contradictoires.

Modèle de statut (court, mais robuste)

• Qu’est‑ce qui est impacté ? Service/périmètre, impact utilisateur.
• Que sait‑on ? Cause sous forme d’hypothèse, pas d’affirmation.
• Que faisons‑nous maintenant ? Étape concrète (Failover en cours, RESTore en cours, validation).
• Quel est le risque ? Fenêtre de perte de données (RPO), risque d’intégrité, risque de sécurité.
• Quand la prochaine mise à jour ? Heure fixe.

Tenez parallèlement un Entscheidungslog : qui a décidé quand d’accepter quel compromis RPO/RTO ? Ce n’est pas de la bureaucratie, mais cela protège l’équipe a posteriori et aide lors des audits.

Pièges de communication

• La technique devient un « Live-Ticker » : un opérateur ne devrait pas être à la fois en train de gérer le RESTore et de répondre aux parties prenantes.
• Précision trompeuse : « De nouveau en ligne dans 12 minutes » est généralement peu sérieux. Mieux : « RESTore en cours, prochain jalon : validation dans env. 30–45 minutes, puis ETA ».
• Pas de « Go » clair : qui autorise la reprise des écritures ? C’est un point de décision défini.

Prüfschritte und Troubleshooting: Wenn Failover/RESTore nicht wie geplant läuft

Dans les reprises réelles, ce sont souvent quelques classes d’erreurs récurrentes. Un bon runbook contient donc de courts blocs de dépannage avec « Symptôme → Vérification → Mesure ».

Symptôme : Anwendung verbindet sich nicht zur DB nach Failover

• Vérification : le DNS pointe‑t‑il encore vers l’ancien endpoint ? TTL/cache ? Load Balancer Health Checks ?
• Vérification : règles de firewall dans le segment DR ? Security Groups ? NAT ?
• Mesure : vérification du Name → IP, accessibilité du port, puis vérification de la config applicative/secrets.

Un contrôle réseau rapide depuis un App-Host (exemple) peut ressembler à :

#!/usr/bin/env bash
set -euo pipefail

DB_FQDN="db.service.example"
DB_PORT="3306"

echo "DNS-Auflösung:";
getent hosts "$DB_FQDN" || true

echo "Port-Test:";
( echo > /dev/tcp/$DB_FQDN/$DB_PORT ) && echo "Port offen" || echo "Port blockiert/timeout"

Pourquoi cela aide : il sépare la résolution de noms de la vérification de la disponibilité d’un port. Où cela échoue : /dev/tcp est spécifique à bash et n’est pas disponible partout ; dans de tels environnements, vous aurez besoin de nc/telnet ou d’outils appropriés.

Symptom: Replica ist nach Failover read-only oder verhält sich inkonsistent

• Vérifier: read_only/super_read_only défini(s) ? (Dans certains déploiements HA, c’est intentionnel.)
• Vérifier: la configuration de réplication est-elle encore active et continue-t-elle d’écrire « von hinten » ?
• Mesure: établir un rôle primaire clair, placer les autres nœuds en lecture seule et/ou les reconnecter comme réplicas.

Symptom: RESTore dauert „endlos“

• Vérifier: performance du stockage (IOPS/débit), goulets d’étranglement CPU, compression/déchiffrement
• Vérifier: volume cible trop petit ou système de fichiers inadapté (p. ex. noatime, options de journalisation)
• Mesure: paralléliser uniquement là où les outils et le stockage le supportent ; sinon activer un plan B.

Runbook-Qualität messbar machen: „Definition of Done“ für DR

Sinon, les runbooks deviennent des documents que personne n’ose toucher. Définissez des critères de qualité objectifs :

• Exécutable en conditions réelles: tous les accès, chemins et dépendances sont présents (y compris hors-ligne).
• Testé: chaque variante critique du runbook (Failover, RESTore, PITR) a été pratiquée au moins une fois.
• Horodatage: dernier test, dernière modification, rôle responsable.
• Validation: critères d’acceptation clairs définissant quand « service rétabli » s’applique.
• Repli: pour chaque étape majeure, il existe une option de retour en arrière.

Pour MariaDB, il est conseillé d’ajouter un rythme régulier : petites simulations de RESTauration (p. ex. mensuelles) avec un jeu de données minimal et un exercice End-to-End plus complet (p. ex. trimestriel ou semestriel) selon le taux de changement et le niveau de risque.

Praxisfazit: Desaster-Recovery ist ein geübter Betriebsvorgang

En cas de sinistre, les équipes qui ont pris les décisions à l’avance sont avantagées : RTO/RPO par service, chemins clairs de Failover vs. RESTore, accès sécurisés, et un schéma de communication qui protège la technique. Un runbook n’est alors pas de la « documentation », mais un outil : il rend les étapes reproductibles, réduit les erreurs sous stress et permet de tirer des améliorations concrètes de chaque test.

Si vous ne retenez qu’un point : ne planifiez pas la RESTauration comme un « problème de sauvegarde », mais comme un redémarrage de bout en bout incluant DNS, identités, secrets, jobs, monitoring et processus d’autorisation. Ce n’est que lorsque les tests de Failover et les simulations de RESTore réussissent régulièrement que la reprise en cas de sinistre devient autre chose qu’un espoir.

Pour ce sujet, le Disaster Recovery Runbook et la communication d’incident sont également importants. Cet article cadre ces aspects de manière compréhensible et montre ce qui compte au quotidien.