Test de restauration des sauvegardes

Un audit vérifie qu’une politique existe, que des tâches réussissent et que des copies sont stockées. Un test de restauration vérifie que les données reviennent réellement, dans le délai annoncé, avec les clés, les droits et les dépendances nécessaires. Ce ne sont pas deux niveaux de contrôle interchangeables.

→ Lire l’explication complète de la marmotte

Audit de sauvegarde et preuve de restauration

L’audit répond à des questions de présence : une politique de rétention est-elle définie, les travaux planifiés se terminent-ils sans erreur, les copies sont-elles chiffrées, les journaux sont-ils conservés, les accès sont-ils séparés ? Ces contrôles sont nécessaires. Ils ne prouvent pas que l’application restaurée démarre, que son schéma est cohérent ou que les utilisateurs retrouvent les données attendues.

Le compromis central est net : tester coûte du stockage temporaire, des ressources de calcul, du temps d’exploitation et parfois une fenêtre d’isolement réseau. Ne pas tester économise ces ressources jusqu’au premier incident, puis transforme le délai de reprise annoncé en hypothèse décorative. La recommandation est donc de tester toute chaîne de restauration, pas seulement la lecture d’une archive, avec une fréquence indexée sur le délai maximal de perte de données accepté.

Un audit peut constater qu’un fichier de sauvegarde est présent, signé et chiffré. Il ne détecte pas forcément les cas suivants :

le compte de restauration n’a plus le droit de lire le dépôt ;
la clé de chiffrement a été supprimée ou son accès dépend d’un fournisseur indisponible ;
l’archive contient une base de données cohérente au niveau des fichiers, mais incohérente au niveau transactionnel ;
la version cible ne sait plus lire le format produit par une version ancienne ;
les secrets applicatifs, certificats et paramètres de connexion ne sont pas inclus ;
la restauration atteint le point de récupération, mais l’application ne reconstruit ni index, ni files de messages, ni état de cache nécessaire.

La mention « succès » dans une console de sauvegarde signifie généralement que l’outil a terminé sa copie. Elle ne signifie pas que le service est récupérable. Les dashboards adorent les coches vertes : elles ne redémarrent pas une base de données.

La page Continuité, sauvegardes, PRA/PCA et haute disponibilité rappelle la différence structurelle entre sauvegarde, continuité et reprise. Une sauvegarde testée est une brique de reprise, pas une garantie de disponibilité. Elle ne remplace ni une architecture tolérante aux pannes ni un plan de bascule.

RPO, RTO et données réellement récupérables

Le RPO (Recovery Point Objective), ou objectif de point de reprise, définit la perte de données maximale acceptable. Le RTO (Recovery Time Objective), ou objectif de délai de reprise, définit le temps maximal acceptable pour remettre le service à disposition. Ces objectifs ne se déduisent pas du contrat d’un outil de sauvegarde. Ils se mesurent pendant une restauration complète.

Une copie nocturne ne permet pas un RPO de quinze minutes, même si la réplication du stockage produit beaucoup de bruit rassurant. Pour atteindre un RPO court, il faut capturer les journaux de transactions, les événements ou les modifications incrémentales avec une horloge fiable et une conservation suffisante. Pour une base relationnelle, cela implique souvent une sauvegarde complète et une chaîne de journaux permettant une restauration à un instant donné.

Le test doit mesurer quatre temps distincts :

l’autorisation d’accès au dépôt et aux clés ;
le transfert et le déchiffrement des données ;
la reconstruction technique du service ;
la validation fonctionnelle et la remise en accès.

Additionner seulement la durée du téléchargement produit un RTO fictif. Dans la plupart des environnements, le transfert n’est qu’une partie du délai. Les migrations de schéma, la reconstruction des index, les contrôles d’intégrité, la génération de certificats et le remplissage de caches prennent du temps. Le cache, cet animal domestique qui devient soudain une dépendance de production dès qu’il faut repartir de zéro.

Un test fiable choisit un point de restauration connu, pas toujours le dernier. Restaurer uniquement la sauvegarde la plus récente ne vérifie ni la rétention effective ni la capacité à revenir avant une corruption détectée tardivement. Il faut tester au moins un point récent, un point situé à la limite de rétention opérationnelle et un point antérieur à une modification majeure de version ou de schéma.

Chaîne cryptographique, clés et accès de secours

Le chiffrement des sauvegardes protège la confidentialité des copies, mais il crée une dépendance directe entre restaurabilité et disponibilité des clés. Une sauvegarde chiffrée avec une clé perdue est parfaitement protégée contre tout le monde, y compris contre son propriétaire. La cryptographie ne négocie pas avec le calendrier d’astreinte.

Lorsqu’une DEK (Data Encryption Key), ou clé de chiffrement des données, est chiffrée par une KEK (Key Encryption Key), ou clé de chiffrement de clé, le test doit vérifier la chaîne complète : accès au coffre de clés, autorisation de déchiffrement, version correcte de la KEK et disponibilité du service de gestion de clés. Si cette fonction repose sur un HSM (Hardware Security Module), ou module matériel de sécurité, la reprise doit tester l’accès au module, ses politiques d’autorisation et la restauration de ses métadonnées. Une clé importée sans politique d’usage ou sans sauvegarde des objets associés ne suffit pas.

La rotation des clés ajoute un piège classique. Après rotation, les sauvegardes anciennes doivent rester déchiffrables pendant toute leur période de rétention. Supprimer une ancienne version de clé dès qu’une nouvelle existe rend les archives historiques inutiles. La politique correcte sépare la rotation de chiffrement, qui limite l’exposition future, de la destruction de clé, qui rend les données associées irrécupérables.

Pour les mécanismes de chiffrement et de stockage des secrets, consulter aussi Protéger les données au repos. Le point à retenir reste moins glamour que les slides de gestion de clés : une restauration doit être exécutée avec des identités distinctes de celles qui administrent la production, mais ces identités doivent exister avant la crise.

Exemple de test de restauration PostgreSQL isolé

L’exemple suivant valide une sauvegarde logique PostgreSQL dans une instance locale isolée. Il contrôle que l’archive est lisible, que les objets sont recréés et qu’une requête applicative minimale retourne des données. Il ne doit jamais être lancé sur une instance de production : restaurer dans le mauvais serveur est une forme coûteuse de courage.

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

# Prérequis : PostgreSQL installé, archive créée avec pg_dump au format custom.
# La variable BACKUP_FILE pointe vers une copie locale de l'archive à tester.
# La base cible ne doit contenir aucune donnée de production.
: "${BACKUP_FILE:?Définir BACKUP_FILE, par exemple /var/tmp/app.dump}"
TEST_DB="restore_validation"

# Créer une base temporaire, restaurer, puis vérifier une donnée métier attendue.
dropdb --if-exists "$TEST_DB"
createdb "$TEST_DB"
pg_restore --exit-on-error --dbname="$TEST_DB" "$BACKUP_FILE"

# Remplacer la requête par un invariant réel de l'application.
# Une table présente ne prouve pas que les données sont utilisables.
psql --tuples-only --no-align --dbname="$TEST_DB" \
  --command="SELECT count(*) FROM public.users WHERE email IS NOT NULL;"

# Vérifier l'intégrité logique déclarée par PostgreSQL.
psql --dbname="$TEST_DB" \
  --command="VACUUM (ANALYZE, VERBOSE);"

# Nettoyer seulement après collecte des journaux et métriques du test.
dropdb "$TEST_DB"

Ce test ne couvre pas les journaux de transactions, les rôles, les extensions, les fichiers externes ni les objets hors base. C’est précisément son intérêt : chaque dépendance absente apparaît comme une exigence à intégrer au scénario suivant. Une restauration qui nécessite un partage de fichiers, un annuaire d’identité ou un certificat client doit les déclarer dans le périmètre de test.

Attaques contre les sauvegardes et contre-mesures

Les sauvegardes sont une cible prioritaire des attaques par chiffrement malveillant. Un attaquant qui contrôle les identifiants de production tente souvent d’effacer les points de restauration, de réduire la rétention ou de chiffrer le dépôt avant d’attaquer les données principales. Une copie connectée en écriture permanente au même domaine d’administration n’est pas une dernière ligne de défense, c’est une deuxième victime avec un nom différent.

La contre-mesure minimale est l’immuabilité temporelle : pendant une durée définie, une copie ne peut être ni modifiée ni supprimée, y compris par l’administrateur courant. Cette propriété doit être fournie et testée par le dépôt lui-même. Une règle applicative ou un script de suppression « normalement interdit » s’effondre dès qu’un compte privilégié est compromis.

La règle 3-2-1 reste valable : trois copies, sur deux types de stockage, dont une hors du domaine de défaillance principal. Elle ne garantit toutefois ni l’intégrité applicative ni la confidentialité. Ajouter une quatrième copie inutile dans le même compte cloud ne crée pas une séparation, seulement une facture plus créative.

Le test de restauration doit aussi être cloisonné. Restaurer une sauvegarde compromise dans un réseau connecté à la production peut réintroduire un code malveillant, des comptes persistants ou des tâches planifiées hostiles. L’environnement de validation doit disposer de règles réseau restrictives, d’identifiants non réutilisables et d’une journalisation indépendante. Les contrôles d’intégrité de fichiers détectent une altération accidentelle ou une corruption connue, pas nécessairement une donnée malveillante présente avant la sauvegarde.

Exploitation : fréquence, supervision et critères d’acceptation

Tester une archive une fois par an satisfait parfois un tableau de conformité, pas une exigence opérationnelle. La fréquence doit suivre la vitesse de changement : après modification du moteur de base, du format de sauvegarde, de la politique de chiffrement, du fournisseur de stockage, des rôles d’accès ou du schéma applicatif, exécuter un test avant de considérer le changement terminé.

Chaque test doit produire une preuve exploitable :

identifiant exact du point restauré ;
horodatages de début et de fin ;
versions du moteur, de l’outil et du format ;
empreinte cryptographique de l’archive si disponible ;
identité ayant exécuté l’opération et identité utilisée pour lire les clés ;
résultat de contrôles de cohérence techniques et métier ;
écarts mesurés face au RPO et au RTO ;
actions correctives avec un propriétaire et une échéance.

La supervision doit alerter sur l’échec du test, mais aussi sur son absence. Une tâche qui ne s’exécute plus sans générer d’erreur est fréquente après une modification d’authentification, une expiration de certificat ou une saturation du stockage temporaire. Vingt ans d’exploitation apprennent que l’alerte la plus dangereuse est souvent celle qui n’a jamais été configurée.

La restauration ne garantit pas l’absence de fuite avant incident, la conformité réglementaire, la disponibilité pendant la reprise ni la correction de la cause racine. Ces propriétés doivent venir du contrôle des accès, de la détection, de l’architecture de continuité et de la remédiation. Les sauvegardes relèvent de la protection des données, pas d’une amulette technique contre tous les désastres.

🐝 Ce qui arrive si on s’en passe

Sans test de restauration, la première exécution réelle de la procédure a lieu pendant l’incident, avec un opérateur d’astreinte qui découvre les dépendances une par une : chaque manque (droit, clé, certificat, fichier externe) impose une nouvelle tentative, et les essais successifs consomment le temps pendant lequel la rétention continue d’écraser les points de reprise les plus anciens. Faute de durée mesurée, aucun arbitrage n’est possible entre réparer l’existant et repartir d’une copie, et la décision se prend sans savoir si la restauration prendra deux heures ou deux jours. Les engagements de délai communiqués aux métiers restent invérifiables, donc indéfendables. Enfin, sans preuve datée d’une restauration réussie, rien ne permet de distinguer une archive simplement illisible d’une archive altérée avant l’incident, ce qui prive l’analyse post-incident d’un point de comparaison fiable.

🦫 Explication de la marmotte 🍫

Une sauvegarde est une copie de données conservée pour pouvoir revenir à un état antérieur après une panne, une erreur ou une attaque. Un contrôle administratif peut vérifier qu’une copie existe et qu’un programme annonce avoir terminé. Cela ne prouve pas que les données pourront redevenir utilisables.

Un test commence par choisir une copie précise. Il faut ensuite obtenir l’autorisation de la lire, accéder aux clés qui servent à la déchiffrer, transférer les fichiers vers un environnement séparé, puis reconstruire le service. Une base de données doit pouvoir relire ses fichiers, retrouver ses utilisateurs, ses règles et parfois les journaux qui permettent de revenir à une heure donnée. L’application doit ensuite démarrer et produire un résultat attendu, par exemple retrouver un compte, une commande ou un document.

Le test mesure le temps nécessaire et compare ce temps à la limite décidée pour remettre le service en route. Il vérifie aussi l’âge des données retrouvées, car une copie trop ancienne peut être inutilisable même si la restauration réussit.

Quand le test échoue, la cause peut être une clé supprimée, un droit d’accès retiré, un fichier incomplet, une version devenue incompatible ou une dépendance oubliée. Le résultat attendu n’est pas seulement « archive lue ». Le résultat attendu est « service remis en état avec des données cohérentes, dans le délai annoncé ».

Pages voisines

La citent

Test de restauration des sauvegardes

Elle cite

Test de restauration des sauvegardes

Test de restauration des sauvegardes

Audit de sauvegarde et preuve de restauration

RPO, RTO et données réellement récupérables

Chaîne cryptographique, clés et accès de secours

Exemple de test de restauration PostgreSQL isolé

Attaques contre les sauvegardes et contre-mesures

Exploitation : fréquence, supervision et critères d’acceptation

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines