Aujourd'hui, je vais te présenter une récupération de données assez particulière sur un SSD SATA 2,5 pouces BIWIN M100 de 512 Go, âgé d'à peine un mois.

Oui, oui, UN MOIS ! ^^

Le client m'apporte son ordinateur portable Lenovo qui refuse de démarrer Windows.

Le SSD n'est plus reconnu dans le BIOS, et forcément, impossible de démarrer le système d'exploitation.

Le problème, c'est que le client possède environ 40 Go de photos et vidéos personnelles très importantes, notamment des souvenirs de famille, de mariage et de naissance de ses enfants.

Autant dire que perdre ces données n'est pas vraiment envisageable.

Et tu vas voir que ce SSD va me faire passer par toutes les émotions possibles. ^^

Premier diagnostic : un SSD qui refuse de répondre

Je commence par retirer le SSD du PC portable pour le tester directement sur mon ordinateur d'atelier.

Premier constat : en SATA natif, le SSD est parfois absent ou ne s'initialise pas correctement.

Je décide donc de le connecter avec un adaptateur SATA vers USB 3.0 Ugreen.

Et là, surprise !

Après un temps d'attente relativement long, Windows finit par reconnaître le périphérique.

Le SSD annonce bien sa capacité d'environ 477 Gio, correspondant aux 512 Go commerciaux.

Mieux encore, le Gestionnaire de disques Windows arrive à afficher plusieurs partitions, dont deux grandes partitions de 163 Go et 269 Go.

SAUF QUE…

Les deux partitions apparaissent en RAW.

Hey Jamy, c'est quoi une partition RAW ?

Une partition RAW, c'est un volume dont Windows ne parvient plus à reconnaître ou à lire correctement le système de fichiers.

Normalement, Windows utilise principalement NTFS pour stocker les fichiers.

Mais lorsqu'il n'arrive plus à interpréter les structures nécessaires, il peut afficher RAW.

Cela ne signifie pas forcément que les données ont disparu.

Le problème peut venir d'une corruption du système de fichiers, mais également d'un support de stockage défaillant qui ne répond plus correctement aux commandes de lecture.

Et dans notre cas, c'est cette deuxième hypothèse qui commence sérieusement à m'inquiéter.

HexaScan Expert et DMDE : impossible d'accéder correctement au SSD

Je commence par utiliser HexaScan Expert, mon logiciel habituel de récupération de données.

Le logiciel détecte brièvement le SSD et ses volumes, mais rencontre des erreurs de lecture.

Après l'analyse des périphériques, le BIWIN n'apparaît même plus dans la liste des disques exploitables.

Mouais… pas terrible.

Je tente alors DMDE, un autre logiciel de récupération de données.

Cette fois, le SSD est reconnu avec sa capacité de 512 Go, mais DMDE ne retrouve aucune partition et considère l'espace comme non alloué.

Pourtant, quelques minutes auparavant, Windows affichait bien plusieurs partitions !

Autrement dit, le SSD ne répond pas de manière cohérente aux différentes tentatives de lecture.

Et pour ne rien arranger, lorsqu'il est branché directement en SATA, Windows peut même le considérer comme un disque inconnu et non initialisé.

À ce stade, je soupçonne fortement une défaillance interne du SSD : contrôleur, firmware ou mémoire NAND.

Impossible toutefois de déterminer précisément le composant responsable sans diagnostic matériel et firmware plus poussé.

Passage sous Linux : le contrôleur commence à parler !

Puisque Windows n'arrive pas à communiquer correctement avec le SSD, je décide de passer sous Ubuntu Live.

Je commence par brancher le BIWIN directement en SATA sur mon PC d'atelier.

Bonne nouvelle : le BIOS de ma carte mère reconnaît son modèle exact, BIWIN M100 512GB.

Mais une fois Ubuntu démarré, les choses se compliquent.

Le noyau Linux arrive à identifier le SSD et sa capacité, puis rencontre de nombreuses erreurs ATA.

Notamment :

qc timeout after 15000 msecs

Read log failed

failed to set xfermode

disable device

En clair, le SSD répond à certaines commandes, mais finit par se bloquer pendant son initialisation.

Linux tente de réduire la vitesse de communication SATA, sans parvenir à stabiliser le périphérique.

Résultat : aucun disque exploitable n'apparaît dans la liste des périphériques de stockage.

Et en USB ?

Je rebranche alors le SSD sur mon adaptateur Ugreen.

Et là, c'est déjà un peu mieux !

Linux reconnaît le BIWIN, sa capacité de 512 Go et retrouve même ses sept partitions.

Mais les erreurs continuent :

DID_TIME_OUT

I/O error, dev sdb

reset SuperSpeed USB device

Le noyau tente régulièrement de réinitialiser la connexion USB après des commandes de lecture qui expirent.

On n'est donc pas face à une simple partition Windows corrompue.

Le SSD présente bien un comportement anormal au niveau des accès au stockage.

GNU ddrescue : une première récupération à la vitesse de l'ADSL !

Puisque Linux arrive à exposer le SSD en USB, je tente une première imagerie avec GNU ddrescue.

Le principe est simple : créer une copie physique du SSD défectueux sur un support sain, sans modifier les données d'origine.

Pour cela, j'utilise un Samsung Portable SSD T5 de 1 To comme destination.

Je configure ddrescue pour effectuer une première passe sans réessais agressifs, avec un fichier journal permettant de reprendre l'opération si nécessaire.

Et là…

ÇA FONCTIONNE !

Enfin… ça fonctionne, mais à une vitesse absolument catastrophique. ^^

Le débit oscille entre quelques centaines de ko/s et environ 2 Mo/s dans les meilleurs moments.

Après plus de 21 minutes :

• Environ 392 Mo récupérés
• Seulement 0,07 % du SSD
• Une vitesse moyenne d'environ 300 ko/s
• De nombreux délais d'attente et réinitialisations USB observés dans Linux

À ce rythme, on peut envisager plusieurs jours, voire plusieurs semaines pour une image complète.

Même une vieille connexion ADSL aurait presque de quoi se moquer de ce SSD ! ^^

Je décide donc d'interrompre proprement l'opération, en conservant l'image et son journal de progression.

Mais ces 392 Mo sont-ils réellement exploitables ?

Pour le vérifier, j'ouvre la petite image obtenue dans HexaScan Expert.

Et surprise !

HexaScan reconnaît une partition FAT32 avec une arborescence cohérente, notamment les dossiers EFI et BOOT.

Les premières données récupérées sont donc bien exploitables.

Ce ne sont pas simplement des secteurs remplis de données inutilisables.

Il reste de l'espoir !

OpenSuperClone : changement de stratégie

Je décide alors de tester OpenSuperClone 2.5.0, depuis sa distribution Linux dédiée OSC-Live.

OpenSuperClone est un logiciel de récupération par imagerie particulièrement intéressant pour les supports instables.

Il propose notamment plusieurs phases de lecture, des mécanismes de saut des zones difficiles et des paramètres de gestion des erreurs.

Je crée un nouveau projet de récupération, avec le BIWIN comme source et mon Samsung T5 comme destination.

Pour cette première tentative, je privilégie les phases de lecture principales, sans réessais ni phases de finition agressives.

Le but est de récupérer un maximum de données accessibles, sans insister inutilement sur les zones problématiques.

Les premières minutes : toujours aussi catastrophiques

Au démarrage, le débit reste extrêmement faible.

Après environ 41 minutes :

• Seulement 690 Mo récupérés
• Une vitesse moyenne d'environ 280 ko/s
• 114 sauts de zones lentes
• Des temps de réponse pouvant approcher les 30 secondes

Autant dire que le BIWIN ne semble pas vraiment décidé à coopérer.

Mais je remarque quelque chose d'intéressant : OpenSuperClone parvient à progresser en sautant les zones difficiles.

Je décide donc de laisser travailler le logiciel et de surveiller l'évolution.

Et soudain… le SSD retrouve la santé !

Après plusieurs heures, changement radical !

OpenSuperClone commence à atteindre des zones qui répondent beaucoup mieux.

Le débit remonte progressivement.

D'abord quelques Mo/s, puis plusieurs dizaines de Mo/s.

Et finalement…

166 Mo/s en lecture !

Oui, tu as bien lu.

On est passé de quelques centaines de ko/s à plus de 160 Mo/s !

Le logiciel parvient désormais à lire de longues plages de données sans rencontrer systématiquement de nouveaux blocages.

Après 3 h 14 d'imagerie, environ 221 Go sont déjà récupérés.

Et le plus intéressant, c'est que le nombre de sauts reste stable pendant cette période.

Cela suggère que les difficultés étaient particulièrement concentrées dans certaines zones du SSD.

Mais attention : impossible d'affirmer que ces zones correspondent à des blocs NAND physiquement défectueux. Le problème peut également provenir du contrôleur ou de la gestion interne des adresses mémoire.

Image complète de 512 Go en 3 h 43 !

Et finalement, OpenSuperClone termine son travail.

Le logiciel affiche :

• Capacité du SSD : 512,11 Go
• Durée totale : 3 h 43 min
• Débit moyen global : 38 Mo/s
• Secteurs marqués comme récupérés : 100 %
• Zones définitivement classées mauvaises : 0

C'est un excellent résultat, surtout lorsqu'on se souvient que le SSD refusait initialement de s'initialiser correctement.

Une précision importante : 100 % dans OpenSuperClone signifie que le logiciel considère toutes les plages comme récupérées selon ses critères.

Cela ne garantit pas à lui seul que chaque fichier sera parfaitement intact, notamment lorsqu'un SSD présente des problèmes de contrôleur ou de firmware.

La prochaine étape est donc indispensable : analyser les données réellement présentes dans l'image.

HexaScan retrouve toutes les partitions… sans scan !

Je retourne sous Windows avec mon image disque de 512 Go et je l'ouvre dans HexaScan Expert.

Et là…

MAGNIFIQUE !

HexaScan reconnaît immédiatement les sept partitions du SSD, dont :

• SYSTEM_DRV : partition EFI de 260 Mo
• Windows : partition NTFS de 163 Go
• WINRE_DRV : partition de récupération
• LENOVO_PART : partition constructeur
• LRS_ESP : partition système constructeur
• Manu : partition NTFS d'environ 269 Go

Et surtout, les deux grandes partitions NTFS sont directement accessibles sans analyse approfondie !

Je peux explorer leurs dossiers, retrouver les noms des fichiers et conserver leur organisation d'origine.

La partition Manu contient justement une grande partie des photos et vidéos personnelles recherchées par le client.

Autrement dit, on évite une récupération brute par signatures, qui aurait pu faire perdre les noms des fichiers et leur arborescence.

Première extraction : 52,6 Go de données récupérées sans scan

Je commence par extraire les données directement accessibles depuis les partitions Windows et Manu.

Résultat :

52,6 Go de données, répartis dans 9 034 fichiers et 198 dossiers.

On retrouve notamment des photos, des vidéos, des sauvegardes de téléphone et de nombreux documents personnels.

Les noms et l'arborescence sont conservés.

Les premières vérifications visuelles montrent également de nombreuses photos et vidéos accessibles.

C'est déjà un résultat particulièrement encourageant, sachant que le client m'avait annoncé environ 40 Go de souvenirs importants.

Mais je décide de pousser l'analyse un peu plus loin.

Analyse approfondie HexaScan : 58,2 Go extraits !

Je lance ensuite une analyse plus complète de l'image disque.

Cette fois, HexaScan retrouve également d'autres entrées de fichiers, dont certains éléments précédemment supprimés.

Nouvelle extraction :

58,2 Go de données, 27 038 fichiers et 965 dossiers.

Soit, par rapport à l'extraction sans scan :

• 5,6 Go supplémentaires en volume
• 18 004 entrées de fichiers supplémentaires
• 767 dossiers supplémentaires

Attention : il ne s'agit pas nécessairement de 18 004 fichiers uniques supplémentaires.

Une analyse approfondie peut retrouver des doublons, d'anciennes versions et des fichiers supprimés dont les données ne sont pas toujours intactes.

Je conserve donc les deux extractions séparément, afin de ne pas mélanger inutilement les fichiers actuels avec les anciens éléments retrouvés.

Les données sont sauvegardées sur mon serveur NAS, indépendamment du SSD défectueux.

Et le plus incroyable… le SSD redémarre Windows !

Tu pensais que l'histoire était terminée ?

Eh bien non ! ^^

Après toutes ces opérations, je replace le BIWIN M100 dans le PC portable du client pour effectuer une dernière vérification.

Et là…

WINDOWS DÉMARRE !

Oui, le même SSD qui était invisible dans le BIOS, qui provoquait des timeouts ATA et USB, et qui refusait de lire correctement ses données.

Il démarre maintenant Windows comme si de rien n'était !

Alors, le SSD s'est-il réparé tout seul ?

Pas nécessairement.

Pourquoi un SSD peut-il recommencer à fonctionner ?

Plusieurs hypothèses peuvent expliquer ce comportement :

Une instabilité du contrôleur ou du firmware

Le contrôleur peut rencontrer un blocage interne temporaire, puis retrouver un fonctionnement apparemment normal après certaines opérations ou un redémarrage.

Un problème de traduction des adresses mémoire (FTL)

Le FTL, ou Flash Translation Layer, permet au contrôleur de faire correspondre les adresses logiques utilisées par Windows avec les emplacements physiques des données dans les puces NAND.

Une anomalie de gestion interne pourrait provoquer des blocages ou des accès extrêmement lents.

Des difficultés d'accès à certaines zones de NAND

Certaines pages mémoire peuvent être difficiles à lire, nécessitant davantage de corrections d'erreurs ou de tentatives internes.

En revanche, rien ne permet ici de confirmer une réallocation de blocs ou une réparation du FTL.

Et surtout…

UN SSD QUI REDÉMARRE N'EST PAS FORCÉMENT UN SSD RÉPARÉ !

Compte tenu des symptômes observés, je ne considère absolument pas ce BIWIN comme fiable.

Je recommande donc son remplacement, même si Windows fonctionne actuellement.

Le client pourra effectuer cette opération ultérieurement selon son budget.

Conclusion : un SSD presque inaccessible, mais des données retrouvées !

Cette intervention aura été particulièrement intéressante.

Au départ, nous avions :

• Un SSD SATA BIWIN M100 512 Go âgé d'environ un mois
• Un ordinateur incapable de démarrer Windows
• Un SSD absent ou instable dans le BIOS
• Des partitions affichées en RAW
• Des erreurs de lecture sous Windows et Linux
• Des commandes ATA expirant après plusieurs secondes
• Une imagerie initialement limitée à quelques centaines de ko/s

Et au final :

Une image physique complète de 512 Go avec OpenSuperClone.

Jusqu'à 58,2 Go de données extraites avec HexaScan Expert.

Des milliers de photos, vidéos et documents retrouvés avec leur arborescence.

Et même un Windows qui finit par redémarrer sur le SSD d'origine !

Bien entendu, l'extraction des fichiers ne garantit pas automatiquement leur intégrité parfaite. Les données importantes doivent être vérifiées et validées avant de considérer la récupération comme définitivement terminée.

Mais cette intervention montre qu'un SSD non reconnu ou affiché en RAW n'est pas nécessairement synonyme de perte totale des données.

Chaque panne est différente, et les résultats obtenus ici ne peuvent pas être garantis sur un autre support.

Un conseil : ne tente pas de réparer une partition RAW au hasard !

Si Windows te propose d'initialiser ou de formater un disque contenant des données importantes, refuse.

Évite également CHKDSK, les réinstallations de Windows, les mises à jour de firmware et les tentatives répétées sur un SSD instable.

Une mauvaise manipulation peut compliquer, voire compromettre définitivement la récupération.

La priorité doit être de préserver le support et, lorsque son état le permet, de réaliser une image avant toute intervention sur le système de fichiers.

Besoin d'une récupération de données sur SSD ou disque dur à Lyon ?

Chez HTR-Informatique, je prends en charge les problèmes de récupération de données sur HDD, SSD SATA/NVMe, clés USB et autres supports de stockage.

Selon les symptômes et la gravité de la panne, je peux réaliser un diagnostic, une imagerie du support et une extraction des fichiers récupérables.

Certaines pannes nécessitent toutefois une intervention en laboratoire spécialisé.

Si ton SSD n'est plus reconnu, que Windows affiche une partition RAW ou que tes fichiers deviennent inaccessibles, évite de multiplier les tentatives.

Récupération de données