testdisk et photorec sont deux outils libres (GPLv2+) formidables… que l’on souhaite pourtant ne jamais avoir à utiliser ! En effet, les deux sont dédiés à la récupération de données après une panne matérielle, ou une bévue.

Le premier est axé supports de stockage et leurs partitions, le second orienté récupérations de fichiers (mais il est loin de se limiter aux images).

Cocorico : le développeur de ces outils est français, et il a bien voulu répondre à notre sollicitation d’entrevue :).

Bonjour Christophe ! Pouvez-vous présenter votre parcours ?

Quand j’ai commencé à développer testdisk, mon premier outil de récupération de données, j’étais encore étudiant en école d’ingénieur.
Maintenant, cela fait plus de 20 ans que je suis diplômé de l’ESIEA, j’interviens d’ailleurs dans son Mastère Spécialisé Sécurité et Information des systèmes depuis 2004.
Après avoir travaillé dans la sécurité informatique, j’ai travaillé autours des systèmes Linux, du réseau et de la sécurité.
Depuis un peu plus de 10 ans, je suis directeur d’exploitation pour un hébergeur parisien.
Dans le cadre de mon auto-entreprise, je fais de la récupération de données.

Comment avez-vous démarré ce projet ?

Un ami développeur professionnel sous Windows venait d’acheter un nouveau disque dur et pour éviter d’avoir trop de lettres de lecteurs (C:, D:, E:, …) avait décidé de réduire le nombre de partitions de son disque de données ; ce disque contenait 3 partitions.
Il a sauvegardé les données, supprimé les 3 partitions, en a créé 2 et — au moment de restaurer les données — il s’est rendu compte qu’il avait été trop vite et qu’il lui manquait la sauvegarde d’une des partitions.
Sachant que j’avais des connaissances sur le partitionnement des PC (je m’étais intéressé au fonctionnement des virus de boot qui se logeaient dans le premier secteur des disques durs), il m’a contacté.

Armé d’un éditeur hexadécimal, il nous avait fallu la journée pour reconstruire manuellement la table des partitions et récupérer ces données. Un peu plus tard ayant appris les rudiments de la programmation en C, je me suis dit qu’il devait être possible d’automatiser la récupération des partitions et c’est ainsi qu’est né testdisk en 1998.

Pour photorec, il a fallu attendre mon premier appareil photo numérique en 2002. Ayant peur de perdre des photos (effacement par mégarde de photos non sauvegardées, reformatage de la mauvaise carte mémoire…), avant même de partir en voyage, j’ai bricolé un programme en C sous Linux capable de récupérer les photos et vidéos prises par mon appareil photo. C’est ainsi que photorec est né pour récupérer des photos. Il a gardé son nom même s’il récupère des centaines de formats de fichier différents.

Quels sont les points marquants qui ont, selon vous, marqué l’évolution de ces logiciels ?

Les points principaux ayant permis le succès de ces logiciels sont :

• de rendre ces logiciels multiplateformes pour PC : MS-Dos et Linux, puis Windows. La prise en charge de macOS est venu bien plus tard et a eu peu d’impact.
• de distribuer ces logiciels gratuitement. L’utilisation d’une licence opensource (GPL v2+) m’a aussi permis d’avoir quelques contributions.
• d’être plutôt à l’écoute des utilisateurs et d’enrichir les formats de fichiers gérés par photorec. Certains sont vraiment exotiques.
• de la documentation en plusieurs langues à une époque où les traductions automatiques étaient quasi-inexploitables. Mais aujourd’hui, la documentation principale de plus de 60 pages est en anglais.

Un point marquant a été la reconnaissance officielle de l’utilisation de ces logiciels par des organismes étatiques.

testdisk a été conçu pour un public technique, j’ai eu des retours de différents sociétés de récupération de données de part le monde l’utilisant mais en général, elles ne souhaitent pas communiquer sur leur utilisation de logiciels (libres ou du commerce).

Un tournant a eu lieu en 2014 quand le NIST, dans le cadre du Computer Forensics Tool Testing Program (CFTT), a testé et publié ses résultats sur les capacités de photorec. En comparant les résultats de chaque outil, on découvre que photorec a les meilleurs résultats (1^ère place ex aequo).
Ainsi, photorec figure dans le catalogue de logiciels que les agences d’États américains peuvent utiliser.

photorec apparaît dans les diapositives de la formation SecNum Academie de l’ANSSI.

Pourquoi un seul paquet pour deux logiciels, ou pourquoi pas un seul logiciel ?

Quand on parle de testdisk et photorec, il y a aussi fidentify, un outil en ligne de commande qui permet de tester rapidement l’identification de fichiers en utilisant les mêmes parsers que photorec, sans oublier qphotorec, une version graphique de photorec.

Selon les distributions, vous pouvez avoir un package testdisk comprenant testdisk, photorec et fidentify et un package qphotorec pour qphotorec.

testdisk utilise un accès en écriture au disque, photorec n’utilise qu’un accès en lecture. photorec est plus facile d’utilisation que testdisk, c’est presque du next/next/next, il ne fait que du « file carving » (récupération de fichiers par identification des entêtes).

Quelles sont les fonctionnalités les plus attendues que vous pensez implémenter ?

La vérification formelle du code des parsers de photorec est ce qui m’a le plus occupé ces dernières années, je continue de travailler dessus.
Je n’ai pas prévu d’implémenter de nouvelles fonctionnalités dans l’immédiat.

Avez-vous des retours d’utilisateurs, des remerciements de personnes qui ont pu grâce à ces outils retrouver une partie de leur vie numérique, ou de grincheux ?

Perdre une partie de sa vie numérique est très stressant.
De fait, j’ai été confronté à des grincheux très agressifs dont un cas extrême de menaces répétées de mort de la part d’un individu qui n’avait pas pu récupérer ses données. Les hébergeurs de ses messageries successives ont agi rapidement lorsque j’ai signalé ses messages, mais je me suis posé la question à ce moment-là si cela valait bien la peine de m’investir autant pour risquer cette violence numérique.

Les retours positifs des utilisateurs et leurs remerciements sont ce qui a permis de me motiver à continuer de développer sur toutes ces années ce projet.
À une époque, je recevais quotidiennement des mails de remerciements et/ou des donations. C’est moins fréquent désormais, mais c’est peut-être parce que les sauvegardes vers le cloud sont beaucoup plus courantes et qu’ainsi les gens ont moins recours à la récupération de données.

Effectivement, perdre une partie de sa vie numérique est très stressant, avez-vous des conseils à donner sur la sauvegarde ?

Ce sont des conseils très généraux :

• que cela soit au niveau personnel ou au niveau professionnel, il est important de vérifier le périmètre de la sauvegarde. Si vous n’aviez plus que votre dernière sauvegarde, que vous manquerait-il ?
• testez une restauration de données
• si possible, multipliez les sauvegardes (sauvegarde avec historique ou versionning, pas une simple synchronisation)
• dans l’idéal, plusieurs lieux de sauvegarde.

Sur ces projets, y a-t-il d’autres contributeurs ?

testdisk et photorec reçoivent principalement des contributions ponctuelles. J’en profite pour remercier toutes les personnes qui m’ont aidé pour les traductions, pour avoir partagé des fichiers dans des formats exotiques, ou pour avoir contribué au code.
Merci aussi aux personnes ayant participé à la modération du forum et au modérateur actuel !

Y a-t-il des fonctionnalités importantes qui ne seront pas développées, et pourquoi ?

À moins de recevoir des contributions, je ne pense pas pousser davantage le support mac.
Le chiffrement des disques sous Windows va devenir la norme, comme c’est le cas sous macOS. Je pense que cela va freiner le développement de testdisk et photorec. La récupération va devenir bien plus complexe en exigeant un déchiffrement préalable.

Des souvenirs marquants de cette expérience ?

Je crois que l’une des anecdotes qui m’a le plus amusé est celle que j’ai reçue en janvier 2007 : dans un premier mail, l’utilisateur explique qu’un appareil photo a été volé dans sa voiture, mais qu’une semaine plus tard, la police a trouvé le coupable et a pu restituer l’appareil photo. Le contenu avait été effacé, mais grâce à photorec, l’utilisateur avait récupéré plus de 300 photos.

Currently I am recovering over 300 photos using PhotoRec that my sister in law took over the holidays. Our car was broken into and the camera was stolen. A week later the police found the guy! They found the camera, but it had been wiped.
I had read about recovering photo's from flash cards via a story on slashdot, and now here I am.

Quelques heures plus tard, j’ai reçu la suite de l’histoire :

I have recovered some pictures that look to be taken by the thief […]
I am submitting a CD of the data I have recovered to the Detective involved in the case. My little camera was involved in a much larger theft, so hopefully the pictures they took will help nail them all!

Le voleur avait utilisé l’appareil photo, photorec a permis de récupérer des photos ayant beaucoup intéressé le détective en charge du dossier : celui-ci espère découvrir les autres personnes impliquées dans un vol de plus grande envergure.

Avez-vous eu des échanges avec des éditeurs de logiciels similaires (opensource ou propriétaires) ?

photorec a été victime de plusieurs contrefaçons.

Dans un cas, un fabricant de carte mémoire a distribué un logiciel de récupération de données, ce fabricant avait sous-traité le développement qui avait « optimisé » son temps de développement en récupérant le code source de photorec, remplaçant tous les entêtes de copyright et ajoutant une interface graphique.
Après avoir contacté le fabricant, celui-ci a fait rétablir les copyrights manquants et le code a été distribué en GPLv3.

Dans d’autres cas, des développeurs ont volontairement publié des contrefaçons qu’ils revendaient. Après avoir fait fermer leur hébergement plusieurs fois, ils ont fini par trouver un hébergeur bullet-proof, un hébergeur qui ne répondait plus aux plaintes…

Concernant le forum, avez-vous déjà rencontré des difficultés avec le respect du code de conduite ?

La modération sur le forum est obligatoire, les spammeurs sont très nombreux et inventifs en réutilisant par exemple du contenu d’autres sujets. Aucun code de conduite n’a été formalisé.
Le forum ne tient plus que grâce à la présence d’un modérateur, je ne sais pas si cette partie du projet va perdurer.

Quel est votre modèle économique ?

Le projet est né comme un projet personnel et reste géré comme tel.
Je travaille chez Global Service Provider, une société de services et hébergement informatique, qui me permet de disposer gracieusement (Merci à eux) de machines virtuelles (VM), sauvegarde, monitoring pour le projet.
Diverses donations ponctuelles couvrent les frais des différents noms de domaine, mon équipement informatique personnel…

Au niveau personnel, quels logiciels libres utilisez-vous, sur quel système d’exploitation ?

À l’exception des raspberry pi sous Raspbian, les différents ordinateurs de la maison sont sous Fedora Linux.
J’utilise gnome comme environnement graphique, alpine et roundcube pour la messagerie, vim comme éditeur de texte, du docker avec moby, gcc, python…

Et au niveau professionnel ?

Mon ordi portable est aussi Fedora Linux.
Les serveurs Linux que mon équipe et moi gérons sont principalement sous AlmaLinux et Debian.

J’utilise tous les jours ansible (automatisation des configurations), git (versionning), netbox (gestion de datacenters), oxidized (sauvegarde réseau), mediawiki (documentation)…

Merci pour votre disponibilité, et pour ces merveilleux outils !

Ben oui, ce sujet m’intéresse car je suis motivé par la préservation de ce que je considère comme précieux dans les données que je crée ou récupère sur mon PC. En tant que bidouilleur j’ai moi aussi créé un outil pour cela. Il correspond à mon besoin et j'en suis satisfait. Voici mon cheminement.

J’ai fait une recherche sur LinuxFR.org avec le mot sauvegarde et j’ai trouvé des articles et des réactions toutes très intéressantes. Les besoins, les solutions, les mises en œuvre sont très variées. Chacun choisit ou crée selon son ressenti et finit par être satisfait de ce qu’il fait. Chacun partage son expérience, en espérant qu’elle profitera à d’autres. À mon tour.

Le meilleur outil de sauvegarde est celui qu’on utilise et en lequel on a confiance.

Je te propose un jeu : demande à un utilisateur de PC, smartphone… si la destruction inopinée de son appareil entraînerait des pertes de fichiers irrémédiables qui pourraient l’affecter (photos familiales, documents…). Demande ensuite s’il fait des copies et/ou des sauvegardes. Pour beaucoup, tu seras catalogué comme vilain geek alarmiste. Il y a du travail de prise de conscience !

Sommaire

• Notion de sauvegarde
• Que demande-t-on à un outil de sauvegarde ?
• Un script shell écrit sur un coin de table (au début)
• Scripts bash tzsauv
• Subtilités et pièges
• Conclusion

Notion de sauvegarde

Une analyse très courte de la fonction sauvegarde serait « ranger quelque part des données qui permettront de restituer ce que je considère comme précieux ».
Les mots clés sont « ranger » « quelque part » « données » « restituer » « précieux ».
On a deux verbes « ranger » « restituer », deux localisations de données « quelque part » « ce qui est précieux », et une notion de filtrage dans le mot « précieux ».

Un autre point de vue serait de dire qu’une information précieuse doit résider en deux endroits, pour que la défaillance de l’un puisse être compensée par l’autre. Une des conséquences consiste à doubler les archivages : la libération des espaces précieux par la suppression de données inactives doit être précédée de l’archivage des données à supprimer vers deux supports distincts. Une autre conséquence est d’utiliser un média spécifique pour recevoir les sauvegardes (autre que celui où sont les données à sauver).

La défaillance peut être de plusieurs origines : matérielle, corruption du média, utilisateur qui efface/écrase…

Que demande-t-on à un outil de sauvegarde ?

Si je rédigeais un cahier des charges pour un outil de sauvegarde, je ferais les listes suivantes. Je suis dans mon contexte de PC isolé, ayant accès éventuellement à un petit serveur sur le réseau local.

Fonctionnalités de base :

• sauver juste ce qui a été modifié depuis la sauvegarde précédente => opération rapide,
• compression des fichiers archives => prend peu de place sur l’espace de sauvegarde,
• facile à lancer et rapide en exécution => sera lancé souvent => sécurisation accrue,
• filtrage => possibilité de conserver dans les espaces sauvés des fichiers qui n’encombreront pas les sauvegardes,
• robuste => confiance.

Fonctionnalités nécessaires :

• vérification de l’intégrité des fichiers archives engendrés,
• restitution facile malgré le grand nombre de fichiers archives à exploiter,
• restitution qui permette de régénérer (ailleurs) l’espace sauvegardé dans le même état que ce qu’il était au moment d’une des opérations de sauvegarde (accès aux états antérieurs),
• recherche/extraction de fichiers dans le grand nombre de fichiers archives obtenus,
• traçage pour vérifier le bon déroulement des opérations.

On peut ajouter aussi :

• algorithme ouvert et source fourni,
• qui s’accommode de tous types de support de stockage,
• qui utilise des formats standard,
• qui a toutes ses fonctionnalités accessibles en ligne de commande.

Le dernier point permettra d’utiliser l’outil comme une commande classique. On pourra le lancer dans un script bash qui adaptera l’usage au besoin spécifique du moment (ajout de montage/démontage du média de sauvegarde, rsync réseau des fichiers générés…). C’est une commodité qui me manque quand je suis coincé dans l’usage d’un outil cliquodrome.

Un script shell écrit sur un coin de table (au début)

J’ai rencontré le shell lors de mon premier contact avec Unix, en 1987. Au début j’ai eu le sentiment de régresser par rapport à la syntaxe COM des Vax/VMS. Depuis, j’ai appris à apprécier le bash, bien plus commode que ses ancêtres sh csh. Une des philosophies du shell est de combiner des commandes simples et robustes pour en faire une réponse à un besoin. Par exemple ls | wc -l renvoie le nombre de fichiers/répertoires du répertoire courant. Toutefois, il y a des cas sournois où le résultat est faux, on verra plus loin ce que je qualifie de pièges.

Avec les pipelines, les redirections, les variables, les traitements de chaînes de caractères, et tout le reste, on peut construire à l’infini des séquences d’opérations qui s’appuient sur des commandes simples à lancer mais puissantes (genre outil de compression, outil de parcours d’une arborescence de fichiers…). Beaucoup des fonctionnalités du système GNU sont construites comme cela. Un bidouilleur système ne peut pas ignorer le bash. En plus, emacs permet un accès très commode aux man. Je n’ai jamais eu de projet ou de besoin qui me pousse à maîtriser Perl ou Python. Je pense qu’ils sont encore plus puissants que bash.

Comme j’aime bien bidouiller, à la fin du 20^e siècle j’avais dans l’idée de faire un outil de sauvegarde basique qui s’appuie sur un pipeline : une commande find qui sélectionne les fichiers modifiés, tar pour les copier et gzip pour compresser. J’ai fait divers essais. En 2021, je m’y suis mis sérieusement et j’ai découvert beaucoup de subtilités du bash.

Un des problèmes des sauvegardes incrémentales est de deviner si un fichier doit être sauvé, sans avoir à comparer son contenu avec la version sauvée dernièrement (ça coûte trop cher). Il faut se baser sur les paramètres du système de fichiers. Il faut bien choisir ces paramètres (on surveille leur changement), au risque de rater certains fichiers ou alors d’en sélectionner trop. Je me suis arrêté sur la date de modification du statut et le numéro d'inode.

Scripts bash tzsauv

Je pense être arrivé au bout des spécifications avec l’outil tzsauv que j’ai écrit en bash. Il est disponible sur mon site.
Je m’en sers quotidiennement. Selon les jours, j’envoie les fichiers archives sur le 2ᵉ disque ou sur clé USB. Je fais aussi un miroir du répertoire disque des fichiers archives vers GoogleDrive (ceinture et bretelles). Je fais aussi une sauvegarde à longue périodicité (six mois) sur une clé USB dédiée (double ceinture).

Les opérations principales utilisent les commandes standard find sed tar zstd md5sum, le bash sert à enchaîner tout ça et sert aux dialogues. Pour installer, il suffit de copier deux scripts sur le média de sauvegarde (SauverTZ_ProjXY_01.bash tzsauv.bash, total 96k, ajouter éventuellement l’aide Alire.txt), et modifier quelques paramètres dans l’un des scripts (le script lanceur SauverTZ_*.bash). Le lancement peut se faire en ligne de commande ou via l’explorateur de fichiers par Clic-Droit/Actions/LancerDansKonsole.

L’interprétation du bash prend des ressources, mais je pense qu’elles sont négligeables par rapport à celles prises par les E/S et les commandes standard citées ci-dessus. Le compresseur zstd semble être très performant, en temps et en taux de compression. De plus, il est multithread, ce qui lui permet de tirer avantage des processeurs actuels qui gagnent en puissance en augmentant le nombre de cœurs. Le paramétrage de tzsauv permet de choisir parmi plusieurs formats d’archives.

Pour la sauvegarde vers le 2^e disque, j’ai copié sur le Bureau le lanceur de Konsole, puis j’ai renommé la copie et dans ses Propriétés/Application j’ai modifié l’argument (-e ./SauverTZ_ProjXY_01.bash) et le dossier de travail. Du coup, avec juste un double-clic je lance la sauvegarde en mode interactif (-> question « … TOTALE o/n/q ? »). Elle est pas belle la vie ?

Subtilités et pièges

Je fais régulièrement des petits programmes bash pour explorer des détails de fonctionnement soit du bash, soit des commandes. Les man ont beau être détaillés, ils ne peuvent pas tout dire. Pour un bug de tar je suis allé jusqu’à consulter le source C, le corriger par plaisir et vérifier que c’était OK. La remontée du bug n’a pas abouti (personne n’utilise l’option -u de tar ! C’est de la tétrapilectomie, je suis xyloglotte mais pas encore alopécique).

Si tu lances sous bash ls | wc -l puis touch -- 'a'$'\n''b' puis de nouveau ls | wc -l, le nombre renvoyé aura augmenté de deux alors que tu n’as ajouté qu’un seul fichier. C’est normal car le nom du fichier ajouté tient sur deux lignes ! Solution : ls -q | wc -l ou ls --zero | tr '\n\0' '\0\n' | wc -l. Pour voir le résultat de ls -q envoyé à wc -l via le pipeline, entrer ls -q | cat.

Les deux seuls caractères interdits dans les noms de fichiers/répertoires *unix* sont « / » et « \0 » (à méditer).

Je t’invite à créer sous bash un fichier piège par echo "abcd" > $' xyza\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC ', à le sauver avec ton outil, puis à le restituer. Tu verras si ça passe et si le nombre de fichiers est correct. Pour le détruire rm -i *xyza* devrait convenir.
Essaye aussi avec un sous-répertoire mkdir $' xyzp\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC '. Mets-y un fichier, puis fais une sauvegarde totale, modifie le fichier et fais une incrémentale. Ensuite fais un essai de restitution. Joue aussi à modifier le nom du répertoire parent du sous-répertoire piège.
Pour jouer avec ces choses dangereuses, je te conseille de faire une zone à part, ne fais pas courir de risque à ta production. Sur ma Mageia9.2-official, le navigateur Dolphin n’arrive pas à détruire le répertoire piège. Je passe par la ligne de commande.

J’ai rencontré tout plein de pièges et j’en ai imaginé d’autres : un fichier de nom -f, un répertoire de nom -, comment détruire le fichier ? Comment faire un cd vers le répertoire ?
Solutions : rm -f -- -f et cd -- -/ et si le nom du répertoire est dans la variable var cd -- "${var%/}/" (prévoir le cas où var="/").
J’ai découvert que zstd en mode filtre lancé par tar, se met en erreur s’il existe un sous-répertoire de nom - dans le répertoire courant (c’est très particulier, en effet). L’examen des sources de tar et de zstd m’a confirmé le problème, la solution m’a parue simple (inverser l’ordre de deux tests dans le source de zstd) mais la remontée de bug n’a pas abouti. Ce n’est pas grave, je sais maintenant qu’il ne faut pas utiliser tar ... --zstd ..., et je mets plutôt zstd -c[d] dans un pipeline.

J’en raconte un maximum dans le fichier notes01.bash. Toute cette expérience me permet de créer des scripts bash robustes.

Conclusion

Ton outil de sauvegarde est le meilleur, car il te convient.
Fais-toi une idée claire

• de tous tes espaces contenant des fichiers précieux à tes yeux,
• de tous tes espaces de sauvegarde,
• des mécanismes de sauvegarde et de restitution.

Cela participe à la confiance.

N’oublie pas de faire de temps en temps un contrôle d’intégrité des archives et un exercice de restitution. C’est un peu de travail, juste pour vérifier qu’une mise à jour, ou une donnée inhabituelle, ou autre chose, n’a pas mis en défaut la capacité à restituer comme tu l’entends.

Si la restitution est rendue impossible, c’est comme si tu n’avais jamais sauvegardé !

La confiance, en informatique ça se surveille du coin de l’œil
L’informatique est une science exacte pour la machine, pas pour l’homme ; il compense par l’humilité et l’empirisme