Tester la restauration, pas la sauvegarde

Une sauvegarde jamais restaurée ne vaut rien : elle prouve qu’un logiciel a écrit des octets, pas qu’on peut les relire. Pour l’éprouver, on restaure un dossier témoin vers un disque vide, on ouvre trois fichiers au hasard, on compare leurs empreintes avec l’original, et on note la durée et les erreurs dans un journal daté. Tant que cette manœuvre n’a pas été faite, la copie est une hypothèse, pas une protection.

Le magazine allemand Werkstatt Digital documente ce type de manœuvre pour des particuliers et de petits collectifs : ses articles sur les flux de travail documentés séparent la promesse d’un outil de ce qu’on peut vérifier après coup, export, restauration, entretien. C’est un point d’appui utile quand on veut écrire sa propre procédure plutôt que recopier une publicité.

Pourquoi une sauvegarde jamais testée ne vaut-elle rien, et comment éprouver une restauration ?

Une sauvegarde répond à une question technique : les données sont-elles lisibles ailleurs, dans un autre contexte, avec un autre outil ? Tant qu’on n’a pas rouvert les fichiers depuis la copie, on ne sait rien de l’état réel : archive tronquée, permissions perdues, base de données incohérente, chiffrement dont la clé n’est plus disponible. Le NIST, dans sa publication spéciale 800-34 sur la planification de contingence, rappelle que la restauration doit être testée et documentée comme n’importe quel autre processus, avec des responsabilités et des critères de succès.

La manœuvre tient en cinq gestes reproductibles. Un : choisir un jeu témoin, par exemple un dossier de vingt fichiers couvrant texte, image, vidéo courte et une base de données. Deux : restaurer vers un support vierge, jamais par-dessus l’original. Trois : ouvrir chaque type de fichier avec l’application qui l’a produit, pas seulement avec un visualiseur. Quatre : comparer les empreintes (sha256 sous macOS et Linux, Get-FileHash sous Windows) et noter les écarts. Cinq : consigner la date, la version de l’outil, la durée, les erreurs, et refaire l’essai à intervalle fixe, par exemple tous les six mois.

Un test qui échoue est une bonne nouvelle : il révèle le problème avant la panne. Un test qui réussit sans journal ne prouve rien à personne, y compris à soi-même six mois plus tard.

Quelle différence y a-t-il entre synchronisation et version antérieure quand un fichier disparaît ?

La synchronisation aligne deux emplacements sur un état courant. Si un fichier est supprimé d’un côté, la suppression se propage de l’autre : au bout de quelques secondes, il n’existe plus nulle part. C’est un miroir, pas une archive. La version antérieure, elle, conserve des états successifs horodatés ; on peut remonter à la copie d’avant la suppression, à condition que la rétention soit assez longue et que la suppression n’ait pas été synchronisée avant.

Le réflexe utile est de nommer ce qu’on utilise. Un dossier synchronisé entre deux machines n’est pas une sauvegarde. Un instantané local sur le même disque n’est pas une sauvegarde hors site. Une corbeille qui se vide au bout de trente jours n’est pas une archive. Pour chaque outil, on écrit sur une fiche : que se passe-t-il si je supprime un fichier, si je le modifie, si je renomme un dossier, si je restaure une version antérieure ? La réponse se vérifie en trois minutes avec un fichier bidon.

La règle dite 3-2-1 reste un repère simple : trois copies, deux supports différents, une hors site. Elle ne dit pas quel logiciel choisir, elle dit combien de chemins distincts mènent à la même donnée.

Comment comparer deux outils sur l’export, la restauration et l’entretien plutôt que sur la promesse ?

On fixe les critères avant de lire les noms de marques. Quatre colonnes suffisent : export, restauration, protection, entretien. Dans export, on note les formats produits (ouvert, propriétaire, compressé), la possibilité de sortir l’ensemble sans l’outil, et le temps pris pour un volume donné. Dans restauration, on note la procédure exacte, le besoin ou non d’une machine identique, et le comportement en cas de fichier corrompu. Dans protection, on note le chiffrement, la gestion des clés, et ce qui reste lisible si le mot de passe est perdu. Dans entretien, on note la fréquence des mises à jour, la compatibilité avec les systèmes d’exploitation utilisés, et la façon dont les erreurs sont signalées.

La méthode consiste à faire le même essai sur les deux outils, avec le même jeu témoin, le même jour, sur le même matériel. On chronomètre, on photographie les écrans d’erreur, on écrit les résultats dans un tableau. Ce qui distingue deux produits n’est presque jamais la liste des fonctions : c’est le temps de restauration, la clarté du message d’erreur, et la facilité à sortir ses données.

Un critère souvent oublié : la documentation. Un outil dont la procédure de restauration n’est pas écrite noir sur blanc oblige à improviser le jour où l’on est pressé. La documentation fait partie de l’outil.

Comment cataloguer ses fichiers pour retrouver ce qu’on a perdu ?

Un catalogue n’est pas un rangement, c’est une liste vérifiable. Il contient au minimum : le nom du fichier, son emplacement, sa taille, sa date de modification, une empreinte, et l’endroit où se trouve sa copie. On peut le tenir dans un tableur, dans un fichier texte, ou avec un outil qui calcule les empreintes automatiquement.

Sur Mac, la commande 'shasum -a 256' dans le Terminal produit une empreinte pour chaque fichier ; on peut rediriger le résultat vers un fichier texte daté. Sur Linux, 'sha256sum' fait le même travail. Sur Windows, PowerShell propose 'Get-FileHash'. Ces commandes ne dépendent d’aucun logiciel propriétaire et restent lisibles dans dix ans.

Le catalogue sert à deux choses. D’abord à savoir ce qui existe : combien de copies, à quel endroit, sous quel nom. Ensuite à détecter une corruption silencieuse : si l’empreinte d’un fichier change sans qu’on l’ait modifié, quelque chose s’est mal passé. Un catalogue mis à jour une fois par trimestre suffit pour la plupart des usages domestiques.

Comment préparer la perte d’un téléphone et tenir des notes durables ?

La perte d’un téléphone se prépare avant, pas pendant. Trois points à régler : les codes de récupération des comptes, le second facteur, et la liste des applications qui contiennent des données non synchronisées. On imprime les codes de récupération et on les range hors du téléphone. Pour le second facteur, on évite le SMS seul et on préfère une application d’authentification ou une clé matérielle, avec un second appareil en secours. On note enfin, dans un fichier accessible depuis un autre appareil, la procédure exacte de reprise : quels comptes, quels mots de passe, quelles étapes.

Pour les notes, une méthode simple consiste à écrire chaque idée dans un fichier texte séparé, avec un identifiant court, puis à relier les fichiers entre eux par des références. C’est le principe du Zettelkasten : des notes atomiques, reliées, datées. Un dossier de fichiers texte se sauvegarde, se compare et se versionne avec Git sans dépendre d’une application particulière.

Git et le Terminal peuvent faire peur ; on commence dans un dossier test, avec trois fichiers, en apprenant quatre commandes : 'git init', 'git add', 'git commit', 'git log'. On vérifie que l’historique conserve bien les versions antérieures, ce qui est précisément la différence avec une synchronisation. Une fois ce dossier test maîtrisé, on peut y déplacer des notes réelles, sans changer d’outil.

Ce qui rend un flux de travail vérifiable n’est ni la puissance d’un logiciel ni la réputation d’une marque : c’est la trace écrite des essais. Un journal de restauration, un catalogue d’empreintes, une fiche par outil, et une procédure de reprise imprimée. Le reste est une promesse.

Source vérifiée le 15 septembre 2026 : csrc.nist.gov.