Votre sauvegarde est-elle restaurable ? Le test simple qui évite les mauvaises surprises

Définir les données et délais de reprise prioritaires

Une sauvegarde n’est utile que si elle permet de retrouver les données dont vous avez besoin au moment où vous en avez besoin. Avant de lancer un test, je commence donc par définir le besoin de reprise. Pour un indépendant, une association ou une TPE, tous les fichiers n’ont pas la même urgence : un dossier de facturation, un planning ou des documents en cours peuvent être prioritaires, tandis que des archives anciennes peuvent attendre.

Je note les données indispensables, l’emplacement où elles sont sauvegardées et la gêne acceptable en cas d’arrêt. Il ne s’agit pas de promettre un délai universel. La question pratique est plutôt : quelles données faut-il récupérer en premier, jusqu’à quelle date et de quoi dépend leur ouverture ? Cette courte liste évite de tester au hasard un fichier sans rapport avec l’activité.

• données à récupérer en priorité ;
• version ou date minimale attendue ;
• application nécessaire pour les ouvrir ;
• personne autorisée à effectuer la restauration ;
• temps réellement observé pendant l’essai.

Distinguer sauvegarde terminée, intégrité et restauration réussie

Je sépare toujours quatre vérifications. La première confirme que la tâche s’est terminée sans erreur signalée. La deuxième concerne l’accessibilité et l’intégrité de la copie. La troisième consiste à restaurer un fichier et à l’ouvrir. La quatrième est une reprise plus large : application, poste complet ou service métier. Réussir un niveau ne valide pas automatiquement les suivants.

Une sauvegarde crée des copies de données pour les protéger contre la perte ou la corruption. Une restauration récupère ces données vers leur emplacement d’origine ou vers un nouvel emplacement. Cette différence paraît simple, mais elle change la façon de contrôler le résultat : le test doit aller jusqu’au fichier récupéré, pas s’arrêter au journal du logiciel.

Pour un premier exercice, je reste volontairement sur une restauration de fichiers. Une reprise d’application peut demander sa configuration, ses dépendances, ses licences ou une base cohérente. Une reconstruction complète de poste ajoute encore le système, les pilotes, les comptes et le démarrage. Ces scénarios méritent leurs propres procédures ; un échantillon de documents ne suffit pas à les déclarer validés.

Choisir un échantillon de fichiers et versions sans risque

Je prépare un petit échantillon connu avant l’essai : plusieurs types de fichiers réellement utilisés, des tailles différentes et au moins deux dates lorsqu’un historique de versions existe. Par exemple, le lot peut contenir un PDF, un document bureautique, une image et un fichier plus volumineux. Le but n’est pas d’accumuler des centaines d’éléments, mais de vérifier plusieurs chemins représentatifs.

Je relève le nom, la date attendue, la taille approximative et, si nécessaire, un élément visible du contenu. Je choisis des données non sensibles ou je travaille avec les autorisations adaptées. Je ne modifie pas le fichier source pour « faciliter » le test et je ne supprime rien en production pour créer artificiellement une urgence.

• un document récent et un document plus ancien ;
• des formats ouverts par des applications différentes ;
• un fichier assez volumineux pour révéler un problème de transfert ;
• une version antérieure lorsqu’elle est censée être conservée ;
• une référence écrite permettant de comparer le résultat.

Sous Windows, l’Historique des fichiers peut enregistrer périodiquement des copies de fichiers personnels sur un disque externe ou un emplacement réseau. Il permet de parcourir plusieurs versions et de restaurer des fichiers perdus, endommagés ou modifiés accidentellement. Cela fournit un chemin de test possible lorsque cette fonction est réellement configurée ; ce n’est pas une preuve qu’elle protège déjà tous vos dossiers.

Restaurer dans un emplacement séparé et vérifier le contenu

Pour un test non destructif, je restaure l’échantillon dans un dossier séparé, clairement nommé et disposant de suffisamment d’espace. Je refuse l’option qui remplace directement les fichiers en production tant que le comportement exact n’a pas été vérifié. Cette séparation permet de comparer la copie restaurée avec l’original sans écraser une version plus récente.

Je chronomètre l’opération sans transformer cette durée en garantie. Le résultat dépend du volume, du support, du réseau, de l’outil et des contrôles effectués. Une fois les fichiers récupérés, je les ouvre réellement. Je vérifie la bonne version, le contenu attendu et la possibilité de les utiliser avec l’application prévue. Une présence dans l’explorateur ne prouve pas qu’un fichier est exploitable.

Si l’essai échoue, je conserve le message d’erreur et j’évite les répétitions aveugles. Je contrôle le compte utilisé, les droits, l’espace disponible, l’accès à la destination et la version demandée. Selon le cas, le problème peut concerner la copie, le support, l’outil ou simplement la procédure. Le diagnostic vient avant toute conclusion sur l’ensemble des sauvegardes.

Contrôler la présence d’une copie isolée ou hors ligne

Le test de restauration doit aussi regarder l’architecture. La CISA recommande de conserver des sauvegardes hors ligne et chiffrées pour les données critiques, puis de tester régulièrement leur disponibilité et leur intégrité dans un scénario de reprise. De nombreux rançongiciels cherchent les sauvegardes accessibles afin de les supprimer ou de les chiffrer.

Je vérifie donc qu’une copie ne reste pas simplement connectée en permanence avec les mêmes accès que le poste protégé. « Isolée » peut prendre des formes différentes selon l’installation, mais l’objectif est concret : un incident touchant l’environnement courant ne doit pas atteindre toutes les copies en même temps. La stratégie de sauvegarde 3-2-1 aide à organiser cette séparation sans remplacer le test.

Pour plusieurs ordinateurs centralisés, mon guide sur la sauvegarde de plusieurs PC sur un NAS détaille l’inventaire, la fréquence et la copie séparée. Ici, je vérifie en plus qu’un fichier issu de la couche retenue peut effectivement revenir dans un emplacement de test.

Consigner durée, dépendances, erreurs et résultat

Un test utile laisse une trace courte et compréhensible. Je consigne la date, la source de sauvegarde, la destination de test, les fichiers choisis, la version demandée, la durée observée et le résultat de l’ouverture. J’ajoute les dépendances nécessaires : compte autorisé, application, clé, support, connexion ou procédure connue. Je ne note jamais un mot de passe en clair dans ce compte rendu.

Le verdict reste précis. « PDF récent restauré et ouvert » est préférable à « sauvegarde validée ». Si un document est récupéré mais illisible, le test est en échec. Si une ancienne version manque, je le note séparément. Si l’échantillon passe, j’indique exactement ce qu’il couvre et ce qu’il ne couvre pas : il ne prouve ni la reprise de toutes les données ni la reconstruction complète d’un poste.

• réussi : fichiers attendus restaurés, ouverts et comparés ;
• partiel : certains éléments ou versions manquent ;
• échoué : restauration impossible ou fichiers inutilisables ;
• non testé : application, poste complet ou autre scénario hors échantillon ;
• action : correction, responsable et nouvelle date d’essai.

Corriger les lacunes et programmer le prochain test

Une anomalie n’est pas un détail à classer : elle sert à corriger le dispositif avant l’incident. Je traite d’abord la cause observée, qu’il s’agisse d’un dossier exclu, d’une conservation trop courte, d’un droit manquant, d’un support inaccessible ou d’une procédure incomplète. Je relance ensuite un test limité avec le même résultat attendu afin de vérifier la correction.

La CISA recommande que la restauration donne la priorité aux services critiques et s’appuie sur des sauvegardes dont l’intégrité a été vérifiée. J’aligne donc les prochains exercices sur les besoins prioritaires définis au départ. Je programme une nouvelle échéance après une modification importante du système de sauvegarde et selon le niveau de risque, sans inventer une fréquence identique pour toutes les structures.

Après un rançongiciel, la méthode demande des précautions supplémentaires. L’article sur les premières actions face à des fichiers chiffrés explique pourquoi il faut préserver les éléments utiles au diagnostic avant de réinstaller. Un exercice planifié, lui, doit rester isolé, documenté et sans impact sur les données en production.