Analyse
Noter la chronologie avant les hypothèses
Après une perte de données, une chronologie factuelle vaut mieux qu'une cause supposée. Elle délimite la fenêtre de l'incident, distingue la panne initiale des actions de reprise et indique quelles versions de sauvegarde comparer.
Le journal minimal d'incident
Une ligne par événement suffit, avec six champs :
- Date et heure, même approximatives ;
- Personne ou système à l'origine de l'observation ;
- Équipement, volume ou dossier concerné ;
- Message ou symptôme exact ;
- Action réalisée ;
- Résultat observé.
Il faut distinguer les faits des hypothèses. « Le volume demande un formatage à 9 h 12 » est un fait ; « le disque est mort » reste une interprétation tant qu'aucun diagnostic ne l'établit.
Une panne peut être découverte longtemps après son origine. Une suppression synchronisée, une sauvegarde interrompue ou une corruption progressive peut dater de plusieurs jours. Sans chronologie, il devient difficile de choisir la bonne source ou la bonne période à rechercher.
La documentation peut tenir dans six colonnes : horodatage, personne, équipement, observation, action et résultat. Il faut aussi préciser le fuseau horaire ou l'écart connu entre les horloges des équipements : un serveur, un NAS et un poste mal synchronisés peuvent produire une chronologie trompeuse.
| Heure | Équipement | Fait observé | Action | Résultat | Élément conservé |
|---|---|---|---|---|---|
| 08:42 | Serveur de fichiers | Volume absent | Aucun redémarrage | État figé | Photo du message |
| 08:51 | Console de sauvegarde | Tâche en échec | Export du journal | Copie en lecture seule | Journal daté |
L'article sur les erreurs humaines et supports de stockage montre pourquoi les manipulations comptent. L’objectif opérationnel est de transformer ces informations en support de diagnostic.
La chronologie doit inclure les périodes d'incertitude. Si personne ne sait exactement quand la donnée a disparu, il faut noter le dernier moment où elle a été vue et le premier moment où elle a manqué. Cet intervalle aide à choisir les sauvegardes ou versions à comparer.
Analyse
Décrire les supports et les symptômes
Décrire le support consiste à identifier l'objet physique et son rôle logique : disque membre d'un RAID, SSD système, volume de machine virtuelle, carte d'un équipement, copie de sauvegarde ou disque de restitution. La seule référence commerciale ne dit pas où résidait la donnée.
Une étiquette temporaire évite les confusions : identifiant unique, appareil d'origine, position dans l'ensemble, état constaté et mention « ne pas alimenter » si nécessaire. Pour un RAID, l'ordre physique des disques doit être photographié avant tout retrait. Pour une machine virtuelle, les fichiers de configuration et la chaîne de snapshots comptent autant que le disque virtuel principal.
Ne pas modifier pour mieux documenter. Renommer des volumes, monter les systèmes en écriture ou relancer un équipement uniquement pour obtenir une capture peut altérer l'état à préserver. Une note imparfaite vaut mieux qu'une preuve créée au prix d'une nouvelle écriture.
Les symptômes doivent être décrits précisément. Disque absent, bruit, demande de formatage, copie lente, fichier vide, dossier disparu, capacité incohérente ou erreur applicative ne racontent pas la même panne. Les messages exacts, même photographiés, sont précieux.
Il faut aussi conserver les éléments associés : câble, boîtier, alimentation, adaptateur, ordre des disques, captures d'écran, sauvegardes partielles. Ces éléments peuvent expliquer pourquoi le support ne répond plus ou comment la donnée a été modifiée.
La documentation doit éviter les formulations vagues comme "ça ne marche plus". Un diagnostic gagne du temps quand il sait si le support est reconnu, s'il disparaît pendant la lecture, s'il chauffe ou si seuls certains fichiers sont touchés.
Les références matérielles sont utiles sans être excessives. Modèle du disque, capacité, type de boîtier, nombre de disques dans un RAID, appareil d'origine ou carte mémoire utilisée dans un boîtier précis peuvent orienter la méthode. Ces détails évitent de traiter tous les supports comme identiques.
Analyse
Tracer les actions déjà réalisées
Les actions postérieures à l'incident font partie de l'état technique. Redémarrage, réparation automatique, formatage, restauration, remplacement de disque, reconstruction RAID ou copie interrompue doivent être signalés, y compris lorsqu'ils ont semblé sans effet.
Conserver aussi les résultats négatifs
Un essai qui a échoué reste informatif s'il est décrit : durée avant déconnexion, zone où la copie s'est arrêtée, message exact, température ou changement de bruit. Il ne doit pas être répété par un autre intervenant faute de transmission. La documentation réduit ainsi les sollicitations inutiles du support.
Une action peut avoir ajouté des écritures ou modifié des métadonnées. Elle peut aussi avoir produit une copie partielle utile. Le diagnostic doit savoir ce qui existe, ce qui a été remplacé et ce qui a échoué.
La transparence évite les fausses pistes. Une information sensible peut être limitée aux personnes autorisées, mais elle ne doit pas être omise du diagnostic. Si le support doit servir à une expertise ou à une preuve, il faut aussi noter chaque transfert, conserver l'original et calculer les empreintes des copies de travail lorsque le protocole le demande.
Le guide des erreurs à éviter après l'incident explique les gestes risqués. La documentation permet ensuite d'évaluer leurs conséquences sans répéter les mêmes essais.
Il faut conserver les copies partielles au lieu de les remplacer. Même incomplètes, elles peuvent montrer une version, une date ou une structure de dossier. Supprimer une copie parce qu'elle semble imparfaite peut retirer un élément de comparaison utile.
Analyse
Définir les fichiers prioritaires
La priorité doit être formulée comme un critère de réussite, pas comme « tout récupérer ». Nom du dossier, période, format, application attendue et tolérance aux fichiers partiels permettent d'ordonner les lectures et de contrôler la restitution.
La liste de priorité doit associer un nom concret, une période, un format et un critère de validation. « Comptabilité » reste trop large ; « base de facturation, exercice en cours, ouverture dans la version utilisée et présence des écritures de juin » guide réellement l'acquisition et le contrôle.
- Priorité 1 : bloque l'activité, une preuve ou un événement irremplaçable ;
- Priorité 2 : nécessaire à court terme mais disponible partiellement ailleurs ;
- Priorité 3 : archive ou contenu secondaire à traiter si l'état du support le permet.
Les périodes recherchées doivent être précisées. Une entreprise peut avoir besoin du dernier mois, un particulier d'une année de photos, un service de quelques fichiers récents. Cette information influence l'ordre de lecture et la validation.
Il faut aussi indiquer les formats importants. Base, tableur, archive, vidéo, image brute, projet audio ou document bureautique ne demandent pas la même vérification. Un fichier visible dans une arborescence n'est pas forcément exploitable.
La priorité aide à réduire le délai. Sur un support fragile, lire les zones essentielles avant les archives secondaires peut préserver les meilleures chances de récupération. Sans priorité, la lecture risque de se perdre dans des fichiers moins utiles.
Une demande exploitable ressemble à « base de facturation du 1er au 18 mai, ouverture requise dans la version applicative actuelle » ou « vidéos de la caméra 4 entre 14 h 10 et 15 h ». Cette précision guide autant l'extraction que le contrôle final.
Analyse
Faciliter restitution et prévention
La même fiche doit accompagner la restitution. Elle permet de comparer les résultats aux critères annoncés, de distinguer un fichier présent, un fichier ouvert, un contenu validé et une donnée manquante. Un nom de fichier retrouvé n'est pas une preuve d'exploitabilité.
Préparer le passage de relais
Le dossier remis au technicien ou au laboratoire réunit le journal, les photos, l'identité des supports, les copies déjà créées, les sauvegardes disponibles et la liste de priorités. Les secrets d'accès nécessaires doivent être transmis par un canal adapté, séparément d'un colis physique. Cette organisation accélère la compréhension sans multiplier les manipulations.
Elle sert également à la prévention. Si l'incident vient d'une sauvegarde non testée, d'un support mal nommé, d'une synchronisation mal comprise ou d'une erreur de manipulation, la documentation permet de corriger le point faible.
Pour une entreprise, cette trace peut alimenter un plan de récupération plus solide. Pour un particulier, elle évite de reproduire la même erreur sur un nouveau support. Dans les deux cas, la documentation doit rester concrète et exploitable.
Datastrophe travaille mieux avec un support préservé, une chronologie claire et des priorités explicites. Ces éléments ne garantissent pas un résultat complet, mais ils réduisent les incertitudes et évitent des manipulations inutiles.
La bonne documentation est courte, factuelle, versionnée et accessible hors du système en panne. Elle ne remplace pas le diagnostic technique ; elle empêche surtout que les décisions reposent sur des souvenirs contradictoires.
Elle doit aussi rester accessible si le serveur principal est indisponible. Une note exportée, une capture, un message partagé ou une fiche papier peut suffire. Le support de documentation ne doit pas dépendre uniquement du système qui vient de tomber en panne.
Après restitution, cette documentation facilite le retour d'expérience. Elle montre quelles alertes ont été ignorées, quelles sauvegardes ont aidé et quelles actions ont compliqué le dossier. Elle devient alors un outil de prévention, pas seulement une trace de crise.
Sources techniques primaires et limites
Le NIST SP 800-86 recommande une collecte traçable et un examen sur des copies. Ce cadre ne qualifie ni les têtes, les surfaces, les alimentations, le pont d’interface ou les zones non lues du disque reçu, et ne permet pas de confondre détection et récupération vérifiée.
Faire qualifier le dossier « Documenter un incident pour récupérer les données »
Transmettez à Datastrophe le disque et son boîtier éventuel, les alimentations et câbles, la chronologie de l’incident et des essais, les journaux de copie et la liste des données prioritaires. Les codes, clés et éléments d’authentification autorisés sont communiqués par un canal distinct ; ils ne sont jamais inscrits sur le support ni dans le colis.
Datastrophe réalise directement le diagnostic, les contrôles d’intégrité et la récupération dans son laboratoire, avec sa propre équipe. Le diagnostic et le devis sont gratuits. Le transport privé aller et retour est systématiquement pris en charge ; le transporteur déplace uniquement le colis scellé, sans accéder aux données ni les traiter.
Avant tout paiement, le client reçoit le prix proposé et une liste contrôlée. Chaque élément y est classé, dans cet ordre, recoverable_verified, partial, detected_unverified ou unrecoverable. Seuls les éléments recoverable_verified, dont le contenu a été contrôlé et jugé exploitable, sont présentés comme récupérables. Le client paie seulement après avoir accepté la liste et le prix ; la préparation du résultat et la restitution interviennent ensuite.
Si aucune donnée exploitable n’est vérifiée, si la récupération échoue ou si le client refuse la liste ou le prix, aucun frais standard n’est dû. La seule exception concerne une pièce rare, coûteuse et non remboursable : elle ne peut être commandée qu’après une proposition séparée, explicite et chiffrée.