Maintenir et tester les processus de restauration

Je teste mes jeux de sauvegarde à intervalle régulier

Une sauvegarde non testée n'est qu'une hypothèse

Le cours précédent a mis en place, chapitre après chapitre, la sauvegarde du système, des fichiers, de la base de données, des équipements réseau et des machines virtuelles de DKTOYS. Une question reste ouverte, et c'est elle qui ouvre ce dernier cours : ces sauvegardes fonctionnent-elles réellement ? Un fichier de sauvegarde présent sur le NAS, une tâche planifiée qui s'exécute sans erreur visible dans les journaux, ne garantissent pas qu'une restauration à partir de ce fichier réussira le jour où elle sera nécessaire. Cette idée porte parfois le nom de paradoxe de Schrödinger appliqué à la sauvegarde : tant qu'elle n'a pas été restaurée, une sauvegarde est à la fois valide et corrompue — on ne le sait qu'en l'ouvrant.

Ce qui peut rendre une sauvegarde inexploitable sans que rien ne le signale

Plusieurs défaillances passent inaperçues dans un journal d'exécution qui affiche pourtant « succès » :

Ce tableau justifie, à lui seul, l'existence de ce chapitre : un plan de sauvegarde qui s'arrête à « la tâche s'est bien exécutée » reste incomplet. Il doit inclure des tests de restauration, seuls capables de révéler ces défaillances avant qu'un incident réel ne le fasse à la place.

Trois niveaux de test, du plus simple au plus complet

Tester ses jeux de sauvegarde ne signifie pas nécessairement restaurer un serveur entier à chaque contrôle. Trois niveaux, de complexité croissante, se combinent selon leur fréquence :

Ce découpage évite un écueil réaliste pour une équipe de deux personnes comme celle de DKTOYS : viser uniquement le test le plus complet, trop coûteux en temps pour être réellement tenu à intervalle régulier, au risque de ne jamais le faire. Un contrôle d'intégrité automatisé au quotidien, combiné à une restauration ciblée mensuelle et une restauration complète trimestrielle, reste soutenable dans la durée — et vaut infiniment mieux qu'un test complet prévu « quand il y aura le temps », qui ne finit jamais par arriver.

Automatiser le contrôle d'intégrité

Le premier niveau se prête bien à l'automatisation, directement à la suite de la sauvegarde elle-même :

#!/bin/bash
set -euo pipefail

FICHIER="/mnt/nas-local/sauvegardes/bdd/ecommerce_db_$(date +%F).dump"

# pg_restore --list vérifie que l'archive PostgreSQL est lisible et bien structurée,
# sans réellement restaurer les données
if pg_restore --list "$FICHIER" > /dev/null 2>&1; then
    echo "Intégrité vérifiée : $FICHIER"
else
    echo "ALERTE : archive illisible ou corrompue : $FICHIER" >&2
    exit 1
fi

Ce contrôle ne remplace pas une restauration réelle — il vérifie que l'archive est structurellement lisible, pas que son contenu est fonctionnellement correct — mais il détecte déjà une part significative des incidents les plus fréquents, comme un transfert interrompu ou un fichier tronqué.

Documenter chaque test dans une démarche qualité

Un test de restauration qui n'est pas consigné perd une grande partie de sa valeur : impossible de prouver, plusieurs mois plus tard, que la procédure a réellement été validée récemment. Une fiche de test simple, tenue à jour, suffit :

Cette fiche transforme un principe abstrait — « il faut tester ses sauvegardes » — en une preuve exploitable, et permet de mesurer dans le temps si le RTO fixé au premier cours de ce sous-module reste réaliste : un test qui prend systématiquement plus de temps que le RTO annoncé signale que la procédure, ou les moyens qui la soutiennent, doivent être revus.

Un calendrier annuel pour ne pas dépendre de la mémoire

À titre d'exemple, et non comme une donnée issue des supports de formation, un calendrier de test réaliste pour l'équipe de deux personnes de DKTOYS pourrait se répartir ainsi sur l'année :

Ce calendrier répartit l'effort dans le temps plutôt que de le concentrer sur une seule échéance annuelle redoutée : la restauration ciblée mensuelle, tournante d'un système à l'autre, garantit qu'aucun périmètre ne reste plus de quelques mois sans avoir été vérifié, sans jamais représenter une charge disproportionnée pour une équipe réduite.

Que faire quand un test échoue de façon répétée

Un test qui échoue une première fois appelle une correction ciblée, comme illustré dans la fiche de suivi ci-dessus. Un test qui échoue de façon répétée sur le même système signale un problème plus structurel, qui mérite une escalade plutôt qu'une nouvelle correction ponctuelle :

• vérifier si les corrections précédentes ont réellement été appliquées à la procédure de sauvegarde elle-même, et pas seulement contournées le temps du test ;
• réévaluer si le RTO ou le RPO fixés pour ce système restent réalistes compte tenu des moyens réellement disponibles, plutôt que de continuer à viser un objectif que la pratique dément régulièrement ;
• documenter l'échec répété dans le PRA lui-même, pour qu'il reste visible au niveau de la direction et ne se limite pas à une note technique connue de la seule équipe informatique.

Ce qu'il faut retenir

Une sauvegarde qui n'a jamais été restaurée reste une hypothèse, jamais une certitude : fichier tronqué, corruption silencieuse, incohérence interne ou dérive de configuration peuvent tous rendre une sauvegarde inexploitable sans qu'aucune alerte ne le signale au moment de sa création. Combiner un contrôle d'intégrité automatisé, des restaurations ciblées régulières et une restauration complète périodique, le tout consigné dans une fiche de suivi, transforme la sauvegarde d'un acte de confiance en une démarche qualité vérifiable. Les supports de ce cours posent l'objectif de tester ses jeux de sauvegarde sans en détailler la méthode ; ce chapitre s'appuie donc sur les pratiques professionnelles reconnues de validation de sauvegarde, appliquées au contexte de DKTOYS. Les deux chapitres suivants mettent ces tests en pratique sur deux cas concrets : la restauration d'un serveur Windows, puis celle d'une base de données et de ses requêtes.