Diagnostic
Établir la chronologie avant d'expliquer
Après une perte, les faits sont plus utiles qu'une cause supposée. Notez le dernier moment où les fichiers étaient présents, le premier symptôme et les actions lancées ensuite.
Tenir un journal minimal dès le premier constat
L'origine peut être plus ancienne que la découverte. Une suppression synchronisée, une corruption lente ou une sauvegarde interrompue remonte parfois à plusieurs jours.
Le relevé doit au moins identifier :
- La dernière utilisation connue comme correcte ;
- Le premier message, bruit ou comportement anormal ;
- Chaque redémarrage, copie, réparation ou restauration ;
- La source et la destination de toute opération ;
- La personne qui a observé ou autorisé l'action.
Une ligne par événement suffit : heure approximative, machine, support, message, action et résultat. Il faut capturer ces éléments avant qu'ils disparaissent des mémoires ou des journaux.
Les erreurs de manipulation des supports montrent pourquoi les interventions changent le diagnostic. La fiche transforme leur souvenir en information exploitable.
Séparez explicitement ce qui a été observé de ce qui est seulement supposé. « Le volume a disparu après le redémarrage » est un fait ; « le contrôleur est mort » reste une hypothèse tant qu'aucune mesure ne l'établit.
| Moment | Élément à noter | Utilité pour la récupération |
|---|---|---|
| Avant l'incident | Dernière version et sauvegarde connue | Borner la période manquante |
| Premier symptôme | Message, bruit, lenteur ou absence | Orienter le niveau de diagnostic |
| Essais suivants | Outil, durée, source et destination | Repérer les écritures ajoutées |
| Mise à l'arrêt | État et personne décisionnaire | Préserver une référence commune |
Lorsque l'heure exacte manque, encadrez l'incertitude : dernière utilisation correcte et première constatation de la perte. Cet intervalle aide à sélectionner les versions. Ajoutez coupures, redémarrages, mises à jour, remplacements et sauvegardes dans l'ordre, en distinguant fait observé et hypothèse. Notez aussi le fuseau horaire et tout décalage connu entre les horloges du serveur, du NAS et des postes afin de remettre leurs journaux dans une chronologie commune.
Diagnostic
Nommer le matériel et les symptômes
Précisez s'il s'agit d'un disque, SSD, clé, carte, NAS, RAID, serveur, VM ou sauvegarde. Un même message recouvre des risques différents selon la technologie.
Décrivez ce qui se passe réellement : bruit, absence, formatage demandé, copie lente, dossier vide, capacité incohérente ou erreur de l'application.
Ne testez pas pour compléter la fiche. Si le disque claque, chauffe ou disparaît, consignez le symptôme et laissez-le hors tension. La documentation ne doit jamais justifier une sollicitation supplémentaire.
Gardez câble, boîtier, alimentation, adaptateur, ordre des disques, captures et copies partielles. Ces éléments peuvent expliquer l'accès ou les écritures.
Pour un NAS ou un RAID, photographiez les emplacements et attribuez un identifiant à chaque disque avant tout déplacement. Pour un appareil chiffré, conservez les accès autorisés et les informations de récupération sans les inscrire dans un document largement partagé.
Écartez les formulations vagues. Indiquez si le support est détecté, à quel moment il disparaît, s'il chauffe et quelles catégories de fichiers deviennent inaccessibles.
Modèle, capacité, appareil d'origine et composition du RAID apportent assez de précision sans transformer la fiche en inventaire interminable. Numéro de série, position, câble, boîtier, chiffrement et message exact deviennent décisifs lorsqu'ils conditionnent l'accès.
Diagnostic
Consigner tout ce qui a déjà été tenté
Redémarrage, réparation, formatage, restauration, changement de disque, reconstruction RAID et copie interrompue doivent figurer dans l'ordre.
Conserver également les essais sans résultat
Une tentative peut avoir modifié les métadonnées tout en laissant une extraction incomplète mais exploitable. Pour choisir la suite, le diagnostic doit distinguer les transformations apportées des sources encore disponibles.
Indiquez le nom de l'outil, sa durée, le message final et la destination choisie. Une opération interrompue sans fichier visible peut tout de même avoir lu intensivement le support ou modifié une structure logique.
La transparence évite les fausses pistes. Une restauration au mauvais endroit ou une carte formatée doit être connue tôt, sans recherche de responsabilité.
Les gestes à éviter après l'incident détaille les actions risquées. La fiche permet d'en mesurer l'effet sans les reproduire.
Ne remplacez pas une copie incomplète. Elle peut conserver une date, une version ou une structure absente des autres sources. Pour chaque essai, consignez outil, durée, destination, erreurs et modification produite, même si le résultat paraît inutile.
Diagnostic
Définir un résultat vérifiable
Indiquez les fichiers qui donnent de la valeur au dossier : comptabilité, base, photos, séquence vidéo ou archive juridique.
Précisez la période. Une PME peut chercher le dernier mois, une ASBL quelques dossiers récents et un particulier une année de photos.
Nommez aussi les formats : base, tableur, archive, vidéo ou projet audio ne se valide pas de la même manière. Pour rendre la priorité exploitable, précisez :
- Le dossier ou le nom attendu ;
- La période réellement nécessaire ;
- Le format et l'application de lecture ;
- Une taille ou un nombre d'éléments plausible ;
- La personne capable de confirmer le contenu.
Cette priorité réduit le délai et réserve les premières lectures aux zones essentielles lorsque le support se dégrade.
Une base sans ses journaux, un projet sans ses fichiers liés ou une archive qui s'ouvre partiellement ne répond pas encore au besoin. Le critère doit porter sur l'usage, pas seulement sur la présence d'un nom dans l'arborescence.
Utilisez des exemples concrets, comme un dossier client et une date, plutôt que « tout est important ». Le contrôle final devient alors possible. Indiquez les formats, application, taille attendue et critère d'ouverture pour que présence et exploitabilité ne soient pas confondues.
Diagnostic
Utiliser la fiche après la récupération
La documentation permet de comparer le résultat aux attentes, de signaler les manques et de séparer fichiers complets et partiels.
Préparer un passage de relais compréhensible
Elle révèle aussi le point à corriger : sauvegarde jamais testée, support mal nommé, synchronisation comprise trop tard ou consigne ambiguë.
Le laboratoire de récupération de données doit pouvoir relier le support reçu, l'acquisition analysée et les fichiers restitués. Un identifiant cohérent, les sommes de contrôle disponibles et un relevé des traitements évitent de confondre plusieurs versions.
Pour une entreprise, une ASBL ou un indépendant, cette trace nourrit un plan de reprise simple. Pour un particulier, elle évite de répéter la même erreur.
Datastrophe travaille plus efficacement avec un original préservé, des événements datés et des priorités claires, sans que cela garantisse un résultat complet.
La fiche doit rester courte, factuelle et accessible. Elle donne un point de départ au diagnostic, pas une explication toute faite. Une personne absente lors de l'incident doit pouvoir la relire et comprendre l'ordre des événements sans interprétation orale supplémentaire.
Conservez-la hors du système touché : note exportée, capture partagée ou feuille imprimée. Elle doit survivre à l'indisponibilité du serveur.
Après restitution, elle facilite le retour d'expérience en montrant les alertes, les sauvegardes utiles et les actions qui ont compliqué le dossier. Conservez-la avec le rapport, les sommes de contrôle et la validation métier, puis transformez les écarts en procédure d'arrêt et de sauvegarde. Une version finale distingue faits, hypothèses et décisions, avec l'auteur et l'heure de chaque ajout. Les captures, journaux et inventaires y sont référencés sans exposer mots de passe ni contenu inutile. Ce dossier permet de vérifier la chaîne entre support reçu, copie analysée et fichiers livrés.
Diagnostic
Sources techniques primaires et limites
Périmètre documentaire — d'un incident de perte de données: Pour documentation d'un incident de perte de données, les références primaires retenues sont NIST SP 800-86. Preuve physique — d'un incident de perte de données: Elles cadrent la préservation, la structure de stockage et la validation, sans prouver l’état physique exact, le comportement du contrôleur, la disponibilité des clés ni la cohérence métier du matériel reçu. Preuve contrôleur — d'un incident de perte de données: Ces points exigent des mesures sur l’ensemble d’origine et des contrôles sur des copies.
Diagnostic
Faire établir un diagnostic contrôlé
Ensemble complet — d'un incident de perte de données: Pour le diagnostic de documentation d'un incident de perte de données, transmettez l’appareil ou le lot complet, les éléments d’alimentation et d’interface associés, l’ordre et les étiquettes, la chronologie des symptômes et la liste précise des données prioritaires. Chronologie d’incident — d'un incident de perte de données: Les accès autorisés passent par un canal protégé distinct ; ne redémarrez pas la source uniquement pour obtenir une nouvelle capture.
Responsabilité du laboratoire — d'un incident de perte de données: Datastrophe effectue directement le diagnostic, les contrôles d’intégrité et la récupération dans son propre laboratoire, avec sa propre équipe. Diagnostic gratuit — d'un incident de perte de données: Le diagnostic et le devis sont gratuits. Limite du transport — d'un incident de perte de données: Le transport privé aller-retour est compris ; le transporteur déplace uniquement le colis scellé, sans accéder aux données ni les traiter.
Liste contrôlée — d'un incident de perte de données: Avant tout paiement, le client reçoit le prix proposé et une liste contrôlée. Classes de vérification — d'un incident de perte de données: Chaque élément est classé, dans l’ordre, recoverable_verified, partial, detected_unverified ou unrecoverable. Déclenchement du paiement — d'un incident de perte de données: Seuls les éléments recoverable_verified, ouverts et jugés exploitables, sont présentés comme récupérables. Résultat non vérifié — d'un incident de perte de données: Le paiement intervient après acceptation de la liste et du prix.
Résultat non vérifié — d'un incident de perte de données: 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û. Pièce exceptionnelle — d'un incident de perte de données: Une pièce rare, coûteuse et non remboursable constitue la seule exception et requiert une proposition séparée, explicite et chiffrée acceptée au préalable.