# [Recovery] Accès hdd sata en défaillance matérielle (clos)

## boozo

'alute (et bonne année à tous au fait   :Smile:  )

Voilà le topo des fêtes de famille : j'ai récupéré en sauvetage un disque sata 2"5 ko avec un bruit de ferraille assez moche dès qu'on le branche en accès rw - même pas question de le voir booter qqch - 

Bref, il y a eu une intervention technique onéreuse dessus (hors chambre blanche je vous rassure) qui a permis semble-t-il de récupérer un certain nombre de données magré ce mais pas l'intégralité.

Curieux de la méthode employée, je me demande pour ma culture comment ont-ils bien pu procéder voire essayer moi même pour le cas où celà m'arriverai à mon tour - donc, je branche le-dit disque sur un support usb et voilà ce qu'on peut voir dans les logs : 

```
Jan  4 21:09:25 kernel: usb 1-1: default language 0x0409

Jan  4 21:09:25 kernel: usb 1-1: udev 3, busnum 1, minor = 2

Jan  4 21:09:25 kernel: usb 1-1: New USB device found, idVendor=152d, idProduct=2329

Jan  4 21:09:25 kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5

Jan  4 21:09:25 kernel: usb 1-1: Product: USB to ATA/ATAPI Bridge

Jan  4 21:09:25 kernel: usb 1-1: Manufacturer: JMicron

Jan  4 21:09:25 kernel: usb 1-1: SerialNumber: 080725BB6F00

Jan  4 21:09:25 kernel: usb 1-1: usb_probe_device

Jan  4 21:09:25 kernel: usb 1-1: configuration #1 chosen from 1 choice

Jan  4 21:09:25 kernel: usb 1-1: adding 1-1:1.0 (config #1, interface 0)

Jan  4 21:09:25 kernel: usb-storage 1-1:1.0: usb_probe_interface

Jan  4 21:09:25 kernel: usb-storage 1-1:1.0: usb_probe_interface - got id

Jan  4 21:09:25 kernel: scsi2 : usb-storage 1-1:1.0

Jan  4 21:09:26 kernel: scsi 2:0:0:0: Direct-Access     Hitachi  HTS542525K9SA00       PQ: 0 ANSI: 2 CCS

Jan  4 21:09:26 kernel: sd 2:0:0:0: Attached scsi generic sg2 type 0

Jan  4 21:09:26 kernel: sd 2:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 GB/232 GiB)

Jan  4 21:09:26 kernel: sd 2:0:0:0: [sdb] Write Protect is off

Jan  4 21:09:26 kernel: sd 2:0:0:0: [sdb] Mode Sense: 34 00 00 00

Jan  4 21:09:26 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through

Jan  4 21:09:26 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through

Jan  4 21:09:31 kernel: sdb:

Jan  4 21:09:31 kernel: sd 2:0:0:0: [sdb] Unhandled sense code

Jan  4 21:09:31 kernel: sd 2:0:0:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08

Jan  4 21:09:31 kernel: sd 2:0:0:0: [sdb] Sense Key : 0x3 [current] 

Jan  4 21:09:31 kernel: sd 2:0:0:0: [sdb] ASC=0x11 ASCQ=0x0

Jan  4 21:09:31 kernel: sd 2:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 00 00 00 00 00 00 08 00

Jan  4 21:09:31 kernel: end_request: I/O error, dev sdb, sector 0
```

Eh oué, pas glop !   :Laughing: 

Impossible de détecter le device pour tenter qqch.

Aussi je m'en remets à vos expériences et/où connaissances en la matière : comment vous y prendriez-vous pour accéder a un disque dans cet état avec probablement au mieux une table en bouillie sinon des secteurs de demarrage qui doivent se barrer en sucette à ce que je lis là ? 

A vot' bon coeur amis techos   :Smile: 

----------

## Gaby

Salut,

J'ai eu le même cas de figure à priori il y a peu avec le disque dur (usb) d'une amie mais même le passage chez un pro n'a pas permis de recup. Considérant son disque et ses données comme perdus, j'ai testé un peu comment faire.

Dans mon cas, impossible de monter la partition (ntfs) via ntfs-3g. La table de partitionnement était lisible et semblait ok avec fdisk.

J'ai réussi à accéder sans problème à quelques données avec photorec, rien réussi à sortir avec testdisk. d'après ce que j'ai compris du problème, le disque de 20 Go était illisible sur la 2eme moitié du disque.

Un DD m'a correctement récupéré les 10 gigas du début mais après c'était que des erreurs d'I/O et j'ai laché l'affaire au bout de 24h avec 17Go récupéré dont probablement 5Go d'erreur et une vitesse à ce moment là de 512 octets / 15min.

Je n'ai pas regardé si ça correspondait au plateau physique mais là ça dépassait mon courage d'investigation.

Je te conseillerai donc un testdisk pour voir ce qui en sort. Un tuto ici

Ca m"interesse de voir ce que tu peux tirer de ton disque et comment.

Gaby

----------

## boozo

C'est aussi ce vers quoi je me destinais au départ dd_recue, badblocks et autres mais j'ai un problème en prérequis : comment avoir le device ? dans /dev je n'ai rien de créé correspondant au(x) sdb(*) !   :Sad: 

Dès que je le branche, il me fait ses bruits de cliquetis metalliques et autres grattages et le kernel me crache ces messages (post ci-dessus) en boucle

J'ai bien tenté d'y accéder via un des /dev/sg* avec les smartmontools mais vu les erreurs d'i/o : il gratte longtemps pour me sortir 3 lignes (sic!) (HITACHI version foo modèle bar) et finir avec "disk is not SMART capable" (asser logique vu l'état du disque)

Pourtant, vu que des données ont été extraites, il doit bien y avoir un moyen de faire sinon d'y accéder autrement   :Confused:  un autre adressage physique p.e. quitte à désactiver hal, udev ou je ne sais quoi d'autre pour éviter la détection ?

----------

## guilc

1) USB ? => virer le boitier USB et brancher direct en SATA pour éviter le contrôleur du boitier USB (contrôleurs souvent pourris d'ailleurs...)

2) Si pas mieux direct en SATA, vu que des données ont été récupérées sans ouvrir les plateaux, je suppute que les données ont été récupérées en utilisant une carte contrôleur alternative (la carte vissée au disque) => donc un échange de carte contrôleur aiderait je pense...

----------

## guilc

 *boozo wrote:*   

> quitte à désactiver hal, udev ou je ne sais quoi d'autre pour éviter la détection ?

 

hal udev et compagnie n'ont rien à voir avec la choucroute : c'est le noyau qui lance l'énumération au branchement du périphérique (opération que tu peux déclencher en envoyant le bon ioctl au bon endroit). udev ne fait que préparer le node une fois l'énumération faite avec les infos que lui refile le kernel, et hal arrive encore bien plus tard (lorsqu'il est encore utilisé)

----------

## boozo

J'aurai bien aimé me passer de cette ralonge usb mais faudra attendre que je change de matos pour avoir du sata  :Razz:  sinon que j'en déniche un en prêt 

L'idée 2 me semble interessante... je regarde ce soir voir si les vis portent des marques voire comment ça se trouve cette chose-là, le prix etc...

ps from message 2 : oui tu as raison - en fait c'est une vieille blague chez moi : en cas de problème, toujours accuser hal/udev   :Laughing: 

----------

## boozo

Bon ok j'ai trouvé une machine avec du sata - ça n'élimine pas totalement un pb de cablage mais bon au moins ça limite un chouilla les hypothèses -

Bilan => pas possible de booter un sysrecsuecd avec le disque branché et rien de mieux si je le plug ensuite ; le comportement est identique à ce que j'avais au départ   :Sad: 

Reste des outils bas niveau/constructeurs p.e. ?

M'enfin comment ont-ils bien pu faire ?!   :Shocked: 

En tout cas s'ils ont démonté le controleur sata du disque comme tu disais : ils s'y sont pris très proprement je vois pas l'ombre d'une marque sur les vis de fixation et vu comme c'est tendre et le couple utilisé au montage "Chapeau !"

----------

## boozo

'alute

après plusieurs essais, je n'arrive à rien : les DFT tools m'ont permis de réparer quelques secteurs mais j'ai l'impression que plus il en répare (ou semble en réparer tout du moins), plus il en trouve de nouveaux défectueux à chaque passe   :Laughing:   J'ai commencé avec des codes 0x70 (cad Corrupted Sector) pour finir avec un 0x73 (cad Device damaged by shock) en refaisant un essai avec les smart capabilities désactivées.

Oui je sais, c'est un peu normal si le problème est électromécanique : plus je tente des choses avec et plus je le dégrade... mais bon il risque rien de pire et j'aimerai bien comprendre comment ils ont procédé 

Sinon en étant patient, testdisk arrive à voir un /dev/sdb (en laissant gratouiller le kernel, au bout de 3 minutes de log identique au premier post, il s'arrête et me pose un device /dev/sdb - joie! ) mais n'arrive à rien avec...

Photorec même topo...   :Crying or Very sad: 

Ils ont peut-être simplement eu de la chance d'arriver "tôt" ; la récupération l'aurait juste endomagé davantage et c'est pourquoi je n'arrive à rien avec ?

Je sèche... any clue ?

Edit: @guilc > Pour tester ton hypothèse en dernier espoir, aurais-tu un petit lien pour m'indiquer comment m'y prendre pour changer le controleur du disque en lui-même ? Y'a-t-il des modèles génériques sinon où en trouver et à quels prix ?

----------

## guilc

A priori, la carte contrôleur doit être remplacée à l'identique. Elle est spécifique au modèle. Après, certains disques utilisent peut-être des cartes contrôleur compatibles, mais ça je sais pas... Et les constructeurs ne communiquent pas spécialement sur ces sujets et préfèrent laisser ce genre de choses aux sociétés spécialisées...

----------

## boozo

Bon allez dans la foulée, je clos également ce thread que je menais en parallèle de mon "archéologie" pour me détendre (sic!)

Le disque n'a rien voulu savoir. Je pense que mes multiples essais n'ont fait qu'agraver une situation déjà très en déclin   :Laughing: 

Tant pis y'a pas de mal mais c'est un peu rageant (grrrr!) j'aurais bien voulu voir ce qu'il était possible de faire si je l'avais eu un peu plus tôt dans les pattes. Je le garde sous le coude sait-on jamais que je trouve une carte controleur en récup pour voir et pis sinon je lui ouvrirai le bidou pour voir l'état des plateaux... m'est avis qu'il doivent être un brin labourés.

Merci pour l'aide en tout cas et (mieux vaut deux fois qu'une en la saison) : pensez aux backup !  :Laughing: 

----------

