Hello,

J'aurais besoin de quelques conseils

J'ai un SSD qui vient de "lâcher" (impossible de booter dessus). Cependant, il répond lorsqu'il est connecté en disque secondaire, donc le chipset n'est pas mort, d'où mon incompréhension. J'ai tenté d'extraire les données de manière brute via dd, mais cela n'a pas marché.

Voici le journal lorsque je connecte le SSD (Intel 160 Go SSD 320 series contenant 1 seule partition NTFS bootable) :

Aug 26 10:42:20 pascal-desktop kernel: [ 1202.965296] usb 3-1: new SuperSpeed USB device number 3 using xhci_hcd
Aug 26 10:42:21 pascal-desktop kernel: [ 1203.560330] usb 3-1: New USB device found, idVendor=174c, idProduct=5106
Aug 26 10:42:21 pascal-desktop kernel: [ 1203.560337] usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Aug 26 10:42:21 pascal-desktop kernel: [ 1203.560341] usb 3-1: Product: AS2105
Aug 26 10:42:21 pascal-desktop kernel: [ 1203.560344] usb 3-1: Manufacturer: ASMedia
Aug 26 10:42:21 pascal-desktop kernel: [ 1203.560347] usb 3-1: SerialNumber: BAD_CTX     0000013F
Aug 26 10:42:21 pascal-desktop kernel: [ 1203.564285] usb-storage 3-1:1.0: USB Mass Storage device detected
Aug 26 10:42:21 pascal-desktop kernel: [ 1203.568690] scsi host3: usb-storage 3-1:1.0
Aug 26 10:42:10 pascal-desktop colord[1556]: (colord:1556): GLib-CRITICAL **: g_variant_new_string: assertion 'g_utf8_validate (string, -1, NULL)' failed
Aug 26 10:42:21 pascal-desktop mtp-probe: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1"
Aug 26 10:42:21 pascal-desktop mtp-probe: bus: 3, device: 3 was not an MTP device
Aug 26 10:42:21 pascal-desktop colord[1556]: (colord:1556): GLib-CRITICAL **: g_variant_new_string: assertion 'g_utf8_validate (string, -1, NULL)' failed
Aug 26 10:42:22 pascal-desktop kernel: [ 1204.568717] scsi 3:0:0:0: Direct-Access     INTEL SS DSA2BW160G3H     4PC1 PQ: 0 ANSI: 5
Aug 26 10:42:22 pascal-desktop kernel: [ 1204.575136] sd 3:0:0:0: Attached scsi generic sg1 type 0
Aug 26 10:42:22 pascal-desktop kernel: [ 1204.575666] sd 3:0:0:0: [sdb] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
Aug 26 10:42:22 pascal-desktop kernel: [ 1204.575907] sd 3:0:0:0: [sdb] Write Protect is off
Aug 26 10:42:22 pascal-desktop kernel: [ 1204.575917] sd 3:0:0:0: [sdb] Mode Sense: 23 00 00 00
Aug 26 10:42:22 pascal-desktop kernel: [ 1204.576158] sd 3:0:0:0: [sdb] No Caching mode page found
Aug 26 10:42:22 pascal-desktop kernel: [ 1204.576168] sd 3:0:0:0: [sdb] Assuming drive cache: write through
Aug 26 10:42:22 pascal-desktop kernel: [ 1204.582709] sd 3:0:0:0: [sdb] Attached SCSI disk

Voici ce que j'ai lorsque je connecte une clef USB normale (qui monte sans problème) :

Aug 26 10:52:01 pascal-desktop kernel: [ 1784.781735] usb 2-1: Manufacturer: Sony
Aug 26 10:52:01 pascal-desktop kernel: [ 1784.781740] usb 2-1: SerialNumber: 2A07112020100
Aug 26 10:52:01 pascal-desktop kernel: [ 1784.784139] usb 2-1: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
Aug 26 10:52:01 pascal-desktop kernel: [ 1784.784154] usb 2-1: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframes
Aug 26 10:52:01 pascal-desktop kernel: [ 1784.785915] usb-storage 2-1:1.0: USB Mass Storage device detected
Aug 26 10:52:01 pascal-desktop kernel: [ 1784.786455] scsi host5: usb-storage 2-1:1.0
Aug 26 10:52:01 pascal-desktop mtp-probe: checking bus 2, device 3: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1"
Aug 26 10:52:01 pascal-desktop mtp-probe: bus: 2, device: 3 was not an MTP device
Aug 26 10:52:01 pascal-desktop colord[1556]: (colord:1556): GLib-CRITICAL **: g_variant_new_string: assertion 'g_utf8_validate (string, -1, NULL)' failed
Aug 26 10:52:02 pascal-desktop kernel: [ 1785.790925] scsi 5:0:0:0: Direct-Access     Sony     Storage Media    0100 PQ: 0 ANSI: 0 CCS
Aug 26 10:52:02 pascal-desktop kernel: [ 1785.795800] sd 5:0:0:0: Attached scsi generic sg1 type 0
Aug 26 10:52:02 pascal-desktop kernel: [ 1785.797498] sd 5:0:0:0: [sdb] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB)
Aug 26 10:52:02 pascal-desktop kernel: [ 1785.798124] sd 5:0:0:0: [sdb] Write Protect is off
Aug 26 10:52:02 pascal-desktop kernel: [ 1785.798148] sd 5:0:0:0: [sdb] Mode Sense: 43 00 00 00
Aug 26 10:52:02 pascal-desktop kernel: [ 1785.798778] sd 5:0:0:0: [sdb] No Caching mode page found
Aug 26 10:52:02 pascal-desktop kernel: [ 1785.798801] sd 5:0:0:0: [sdb] Assuming drive cache: write through
Aug 26 10:52:02 pascal-desktop kernel: [ 1785.804289]  sdb: sdb1
Aug 26 10:52:02 pascal-desktop kernel: [ 1785.806403] sd 5:0:0:0: [sdb] Attached SCSI removable disk
Aug 26 10:52:01 pascal-desktop colord[1556]: (colord:1556): GLib-CRITICAL **: g_variant_new_string: assertion 'g_utf8_validate (string, -1, NULL)' failed
Aug 26 10:52:03 pascal-desktop udisksd[1526]: Mounted /dev/sdb1 at /media/pascal/Pascal on behalf of uid 1000

L'OS utilisé est un Linux Mint, mais j'ai aussi tenté avec une Kali Linux, même résultat. Est-ce que quelqu'un aurait une idée pour tenter de récupérer les données du SSD? J'avoue que de mon côté je sèche... Mais c'est d'autant plus frustrant que le driver répond! Est-ce qu'il n'y aurait pas moyen de récupérer les données brutes même avec un driver peu conciliant?

Toute aide est la bienvenue

Le SSD est branché en SATA ou via un chip USB ?

Que donnes la commande smartctl --all /dev/sda    (si sda correspond à ton SSD)

Bonjour,

Merci pour ta réponse

Le disque a une interface SATA, mais branché via un adaptateur USB. J'ai aussi tenté en le branchant en disque interne directement en SATA, mais il ne monte pas non plus.

Je teste la commande dès que je peux, je te tiens au courant du résultat.

EDIT : Je viens de lancer la manip, voici le réusltat

smartctl --all /dev/sdb

=== START OF INFORMATION SECTION ===
Device Model:     INTEL SSDSA2BW160G3H
Serial Number:    BAD_CTX     0000013F
LU WWN Device Id: 5 001517 a6be8c308
Firmware Version: 4PC10365
User Capacity:    8 388 608 bytes [8,38 MB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Tue Aug 29 15:22:57 2017 CEST
SMART support is: Unavailable - device lacks SMART capability.

A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

Du coup j'ai essayé avec l'argument indiqué, j'obtiens la même chose avec cette fois-ci ce message : "SMART Disabled. Use option -s with argument 'on' to enable it.
(override with '-T permissive' option)". Idem avec le nouvel argument, j'obtiens le message suivant : "SMART support is: Unavailable - device lacks SMART capability. A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options."

Je ne comprend pas trop la taille de volume de 8Mo... C'est aussi la taille du fichier que j'obtiens lorsque je fais un dd, mais je n'arrive pas à le monter ensuite... Voici la commande exacte que j'ai essayé :

dd if=/dev/sdb of=/home/pascal/Documents/image01.iso conv=noerror

Est-ce que tu saurais m'éclairer ?

-
Edité par Pascal.B 29 août 2017 à 15:38:14

J'ai beau chercher, je sèche toujours...

Pas d'autres idées, solutions, propositions ?

Ne branches pas ton SSD en USB pour obtenir les infos SMART. Les adaptateurs USB ne sotn pas toujours comatibles SMART donc empêchent de remonter les infos.

Je viens d'essayer en utilisant une live USB Kali et en branchant le SSD directement sur le port SATA, mais le résultat est le même (à la différence près du sdb qui est devenu sda)...

Tu as le même message d'erreur SMART ?!

Bonjour,

Je pense que le ssd est effectivement mort et que ce que à quoi tu as accès est le chipset du ssd qui, je pense, fait 8,38 Mo. Par ailleurs, le ssd est normalement compatible avec S.M.A.R.T, donc le fait que la commande retourne que le ssd n'est pas compatible avec S.M.A.R.T m'encourage à penser que le ssd t'a effectivement bien laché.

Oui, j'ai exactement le même message d'erreur SMART, y compris en utilisant les arguments -T et -s. Cela ne vient pas non plus de l'OS, sachant qu'en usb je passais par un Linux Mint x64 et qu'en branchant le SSD en SATA je suis passé par une Kali Linux x64 en live.

Je suis d'accord pour le disque, mais je voudrais profiter de ses derniers soupirs pour récupérer ce qu'il contient. Sachant que le chipset répond, j'ai du mal à comprendre pourquoi les données ne sont pas accessibles derrières. Contrairement à un disque dur, cela ne peut pas provenir d'un plateau rayé ou d'une tête de lecture qui a lâché, donc il doit bien y avoir une solution pour extraire le contenu du ssd.

Si le chipset est vraiment aussi peu conciliant, n'y a-t-il pas une solution pour adresser directement les blocs mémoire et récupérer ainsi les données brutes ? Je connais le système de fichier (NTFS), et il n'y a pas beaucoup d'alternatives pour la taille des blocs.

J'ai peur que cela ne soit pas possible. Le chipset peut être tout à fait fonctionnel mais les cellules du ssd peuvent être mortes rendant donc impossibles la récupération des données du ssd.

Essaye avec des utilitaires comme Photorec ou Foremost. Tu auras peut-être plus de chances.

Merci pour ces infos

J'ai tenté avec foremost... Rien :

Foremost started at Fri Sep  1 18:14:43 2017
Invocation: foremost all /dev/sda
Output directory: /root/output
Configuration file: /etc/foremost.conf
------------------------------------------------------------------
File: /dev/sda
Start: Fri Sep  1 18:14:43 2017
Length: 8 MB (8388608 bytes)
 
Num     Name (bs=512)           Size     File Offset     Comment

Finish: Fri Sep  1 18:14:44 2017

0 FILES EXTRACTED

Par contre, testdisk, que j'ai trouvé en lien sur l'une des pages que tu m'as indiquées m'a retourné plus d'infos :

Disk /dev/sda - 8388 KB / 8192 KiB - INTEL SSDSA2BW160G3H

Hidden sectors are present.

size       16384 sectors
user_max   16384 sectors
native_max 312581808 sectors
Host Protected Area (HPA) present.

Mais quand j'ai essayé d'analyser les partitions j'ai eu :

Partition sector doesn't have the endmark 0xAA55

Je ne comprend pas les "secteurs cachés". Cela pourrait peut-être provenir d'une partition de récupération sur le disque (je ne sais plus s'il en a une), ou de l'origine du problème :). Le problème ne viendrait dans ce cas pas du firmware commme je le pensais initialement, mais du bloc mémoire contenant les informations de partitionnement. Est-ce que cela vous semble plausible? Je continue à chercher de mon côté, si tu as d'autres idées/conseils, je suis plus que preneur

-
Edité par Pascal.B 1 septembre 2017 à 20:28:26

Bonjour,

pas d'autres idées, conseils ? J'ai beau chercher, je sèche...

Et autrement est-ce que quelqu'un aurait un retour d'expérience sur la récupération des données par une société privée? Je connais à peu près les taux de réusite pour des HDD, mais pour des SSD je n'ai jamais tenté.