Récupérer les données après une coupure ou un enregistrement corrompu

Trois choses qu'on appelle toutes « corrompu »

Avant toute technique, il vaut la peine de séparer trois situations qui reçoivent le même mot et demandent des réponses très différentes.

1. La session n'a jamais été clôturée. L'alimentation a disparu pendant que l'enregistreur écrivait. Les données sont sur le support ; ce qui manque, c'est la structure qui dit où elles sont.
2. Le support est physiquement endommagé. Feu, écrasement, immersion, ou simplement l'âge. Une partie est lisible et l'autre non, et aucun logiciel ne change ce rapport.
3. La structure est corrompue. Les blocs sont là mais la carte est fausse — une écriture ratée, un contrôleur en défaut, un système de fichiers interrompu en pleine mise à jour.

Le premier cas est le plus fréquent et le plus récupérable. Le troisième est plus rare et généralement récupérable aussi. Le deuxième est celui où la réponse dépend de la physique et non du logiciel, et où le rapport honnête est un pourcentage.

Pourquoi un fichier non clôturé n'est pas un fichier perdu

Quand un enregistreur perd son alimentation en vol, la dernière chose qu'il n'a pas faite est de clôturer le fichier : écrire l'index final, mettre à jour l'entrée de répertoire, marquer la session complète. Tout ce qu'il a fait avant est encore sur le support, exactement tel qu'écrit.

Que cela importe ou non dépend entièrement du conteneur. Si l'enregistrement est une suite de blocs autonomes, chacun portant un motif de synchronisation, sa propre longueur, sa propre voie et sa propre date, alors la structure de fichier n'était jamais porteuse : c'était un confort. La reconstruire consiste à balayer le support et à lire ce qui s'y trouve.

Si en revanche le format a placé son index à la fin, ou ne devenait valide qu'à la fermeture propre, la même coupure détruit un enregistrement physiquement intact. La donnée est présente et inatteignable, ce qui est la défaillance la plus frustrante du domaine.

Comment un balayage bas niveau reconstruit un enregistrement

Un logiciel de récupération n'ouvre pas le fichier. Il lit le support secteur par secteur, ignore complètement le système de fichiers, et cherche dans les octets bruts le motif de synchronisation des blocs.

Chaque candidat est ensuite validé plutôt que cru : l'en-tête s'interprète-t-il, les longueurs déclarées désignent-elles un bloc suivant plausible, le numéro de voie existe-t-il dans le bloc de réglage, la somme de contrôle passe-t-elle, la date est-elle cohérente avec ses voisines ? Un bloc qui échoue est écarté ; un bloc qui passe est un fait.

C'est ici que la longueur du motif de synchronisation cesse d'être un détail académique. Un motif de seize bits apparaît par hasard tous les soixante-cinq mille octets environ de données aléatoires : un balayage produit donc des milliers de faux candidats que la validation doit rejeter. Un motif de plusieurs mots n'apparaît pratiquement jamais par accident, et le balayage devient fiable au lieu d'être statistique.

Les blocs valides en main, la chronologie se réassemble d'elle-même : chaque bloc connaît sa voie, son numéro de séquence et sa date, si bien que l'enregistrement se reconstruit dans l'ordre, avec les trous là où des blocs manquent — et ces trous sont documentés plutôt que lissés.

Ce que le conteneur rend possible

• Une date par bloc, et la chronologie survit même quand un tiers des blocs disparaît. Sans elle, un trou désynchronise tout ce qui suit.
• Un compteur de séquence par voie, et vous pouvez prouver ce qui manque au lieu de le soupçonner. Ce nombre a sa place dans le rapport de récupération.
• Une somme de contrôle, et un bloc récupéré est soit bon soit rejeté, plutôt que d'apparence correcte.
• Un index écrit progressivement plutôt qu'à la fin, et le balayage part avec une avance.
• Et le chiffrement veut dire que la récupération a besoin de la clé. Si la gestion des clés était négligée, la récupération s'arrête là — une décision prise au moment de la configuration, pas au moment de la récupération.

Un support endommagé : ce qui revient

Un module protégé au crash qui a traversé la séquence de qualification est conçu pour que les puces mémoire survivent. En récupérer les données est une opération de laboratoire : le module est ouvert, les puces sont lues directement si l'interface ne fonctionne plus, et le contenu brut est imagé avant toute autre chose.

À partir de là, c'est le même balayage avec une entrée dégradée. Certaines zones sont illisibles, et le résultat est partiel par nature. Ce n'est pas un échec de la méthode : une enquête s'intéresse généralement aux dernières minutes, et les dernières minutes sont les blocs les plus susceptibles d'être intacts, puisqu'ils ont été écrits en dernier et jamais réécrits.

Les limites honnêtes

Il vaut la peine d'être explicite sur ce qui ne revient pas, parce que l'optimisme fait perdre des semaines ici.

• Un bloc écrasé est perdu. Si le support a bouclé et réécrit le début, le début n'existe pas.
• Un support effacé cryptographiquement est perdu, délibérément et complètement. C'est la fonction qui marche.
• Une puce détruite est perdue. La destruction physique n'est pas un problème logiciel.
• Et un enregistrement dont douze pour cent des blocs manquent est un enregistrement dont douze pour cent manquent. La récupération restitue ce qui a été écrit ; elle n'interpole pas, et un outil qui comblerait discrètement les trous serait pire qu'un outil qui les signale.

D'où le fait que le livrable d'une récupération soit deux choses et non une : un fichier, et un rapport de ce qui n'y est pas.

Comment ne pas en avoir besoin

La plupart des récupérations remontent à une décision qui pouvait être prise plus tôt, et aucune n'est coûteuse.

1. Choisir un conteneur bâti sur des blocs autonomes qui se datent eux-mêmes. C'est la seule décision qui détermine si une coupure vous coûte des secondes ou tout.
2. Garder le chemin d'écriture court — petits tampons, validations fréquentes — pour que la quantité en vol au moment de la coupure soit une fraction de seconde.
3. Spécifier un support avec protection contre les coupures, pour qu'un bloc en cours d'écriture ne soit pas corrompu en chemin.
4. Passer le contrôle d'intégrité d'après vol avant que l'appareil ne revole, pour qu'un fichier tronqué soit découvert quand la sortie peut encore être refaite plutôt que trois semaines plus tard.
5. Et décharger. Un enregistrement encore sur le support est un enregistrement exposé à la sortie suivante.