logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 16-09-2017 13:29:38

dejieres
Membre
Lieu : Moselle
Distrib. : Bookworm 64 bits
(G)UI : GNOME
Inscription : 07-02-2017

Récupération de données WD MyBook

Bonjour à tous,

J'ai un WD MyBook 2 To (référence WD2000C033 http://www.trustedreviews.com/reviews/w … dition-ii) dont la carte contrôleur a lâché. Bien entendu, vous devinez le truc, il y a là-dessus quelques fichiers que j'aimerais récupérer, si c'est possible. Bon, rien de vital, mais si ça peut se faire, c'est tant mieux.

J'ai donc extrait les 2 disques de 1 To qui composent la bête, et je les ai branchés sur une carte double sata vers USB (de type HD622).
Le bestiau était configuré en mode 2 To, donc, d'après ce que j'ai pu trouver sur le Net, en RAID 0.

Voilà ce que ça donne :

sudo fdisk -l


Disque /dev/sdg : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 4096 octets / 33553920 octets


Disque /dev/sdh : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 4096 octets / 33553920 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xdf837143

Périphérique Amorçage Début        Fin   Secteurs Taille Id Type
/dev/sdh1                63 3907024064 3907024002   1,8T  7 HPFS/NTFS/exFAT

La partition 1 ne commence pas sur une frontière de cylindre physique.


Le premier disque n'affiche aucune partition. C'est normal ça (j'ai pas trop l'habitude du RAID) ?
À noter que si j'inverse le branchement des deux disques, la partition apparaît toujours sur sdh, jamais sur sdg...

Est-ce qu'il y une chance que je puisse remonter ce RAID pour y récupérer quelque chose ? Est-ce qu'il vaut mieux brancher les disques directement en SATA ?

En ligne

#2 16-09-2017 17:59:18

dejieres
Membre
Lieu : Moselle
Distrib. : Bookworm 64 bits
(G)UI : GNOME
Inscription : 07-02-2017

Re : Récupération de données WD MyBook

Je continue de chercher...

Lorsque je fais ça, ça ne marche pas.

sudo mdadm -Av /dev/md4  /dev/sdg /dev/sdh

mdadm: looking for devices for /dev/md4
mdadm: Cannot assemble mbr metadata on /dev/sdg
mdadm: /dev/sdg has no superblock - assembly aborted



Lorsque je fais ça, j'ai une question à laquelle je n'ose trop répondre...

sudo mdadm -Cv /dev/md4 -l0 -n2 -c64 /dev/sdg /dev/sdh

mdadm: /dev/sdh appears to be part of a raid array:
       level=raid0 devices=0 ctime=Thu Jan  1 01:00:00 1970
mdadm: partition table exists on /dev/sdh but will be lost or
       meaningless after creating array
Continue creating array? n
mdadm: create aborted.

Ça casse tout si je réponds y ?

En ligne

#3 16-09-2017 18:05:56

raleur
Membre
Inscription : 03-10-2014

Re : Récupération de données WD MyBook

Oui, ça casse tout. (suite à venir)

Il vaut mieux montrer que raconter.

Hors ligne

#4 16-09-2017 18:22:42

raleur
Membre
Inscription : 03-10-2014

Re : Récupération de données WD MyBook

dejieres a écrit :

Le bestiau était configuré en mode 2 To, donc, d'après ce que j'ai pu trouver sur le Net, en RAID 0.


C'est sûr ? Le RAID 0 n'est pas la seule manière de combiner la capacité de deux disques. Il y aussi le RAID "linear" qui ne fait que mettre le contenu des deux disques bout à bout.

D'où sors-tu cette taille de "chunk" de 64 Kio ?

Que disent

mdadm --examine /dev/sd[gh]


wipefs /dev/sdg


wipefs /dev/sdh


Il vaut mieux montrer que raconter.

Hors ligne

#5 16-09-2017 18:37:36

dejieres
Membre
Lieu : Moselle
Distrib. : Bookworm 64 bits
(G)UI : GNOME
Inscription : 07-02-2017

Re : Récupération de données WD MyBook

Ça fait quelques années que j'ai ce disque. À l'époque, j'avais configuré ce mode avec l'utilitaire Windows (ou alors, c'était le mode par défaut, je ne me rappelle plus vraiment).
C'est en cherchant sur le Net que je suis tombé sur quelques articles parlant de ça, comme ici par exemple : http://taperssection.com/index.php?topic=142612.0

Les résultats des commandes :

sudo mdadm  --examine /dev/sd[gh]

mdadm: No md superblock detected on /dev/sdg.
/dev/sdh:
   MBR Magic : aa55
Partition[0] :   3907024002 sectors at           63 (type 07)


sudo wipefs /dev/sdg


sudo wipefs /dev/sdh

offset               type
----------------------------------------------------------------
0x1fe                dos   [table de partitions]

En ligne

#6 16-09-2017 19:50:55

raleur
Membre
Inscription : 03-10-2014

Re : Récupération de données WD MyBook

Ni mdadm ni wipefs ne trouvent de méta-données ou signatures de RAID connues sur ces disques. C'est prévisible si l'appareil qui les contenait ne faisait pas tourner un Linux.

Les méta-données RAID, quand elles existent sont situées soit au début du disque (décalant le début de l'espace utile), soit à la fin. Visiblement sur ces disques ce n'est pas au début puisque le MBR et sa table de partition sont dans le secteur 0 du disque. Or par défaut mdadm -C inscrit les méta-données au début des disques, ce qui aurait écrasé des données. En comparant la taille de la partition définie dans la table de partitions et la taille des disques, on peut voir qu'il y a un espace de 13136 secteurs entre la fin de la partition et la fin des disques. Il y a assez d'espace pour demander à mdadm d'inscrire les méta-données à la fin des disques, mais cet espace pourrait aussi contenir des méta-données de format inconnu.

Il est possible d'assembler un ensemble RAID sans métadonnées persistantes inscrites sur les disques, mais il faut alors spécifier toutes les caractéristiques dans la commande.

mdadm --build /dev/md0 --level=0 --raid-devices=2 --chunk=64 /dev/sdh /dev/sdg


mdadm --readonly /dev/md0


Je mets sdh en premier car c'est lui qui contient le MBR.
La seconde commande sert à mettre l'ensemble RAID en lecture seule afin de prévenir toute altération.
La partition devrait être vue comme /dev/md0p1.

cat /proc/partitions


Ensuite, il faudrait lancer une vérification du système de fichiers. Si c'est vraiment une partition NTFS comme l'indique son type, tu peux utiliser des commandes des paquets ntfs-3g et nfts-3g-dev :

ntfsck /dev/md0p1


ntfsfix /dev/md0p1


Si des erreurs sont rapportées, la taille de chunk n'est probablement pas correcte. Il faut arrêter l'ensemble RAID

mdadm --stop /dev/md0


et essayer d'autres valeurs (128...).
Si pas d'erreur, tu peux essayer de monter la partition :

mount -r /dev/md0p1 /mnt

Dernière modification par raleur (16-09-2017 20:00:45)


Il vaut mieux montrer que raconter.

Hors ligne

#7 17-09-2017 12:26:27

dejieres
Membre
Lieu : Moselle
Distrib. : Bookworm 64 bits
(G)UI : GNOME
Inscription : 07-02-2017

Re : Récupération de données WD MyBook

Merci raleur smile

J'ai essayé avec plusieurs valeurs de chunk différentes, mais rien à faire, ntfsck échoue systématiquement. Résultat pour 64 :

sudo ntfsck /dev/md0

Loading $MFT runlist failed. Trying $MFTMirr.
file record corrupted at offset 1000198144000 (0xe8e0748000).
Loading $MFTMirr runlist failed too. Aborting.
Inode is corrupt (0): Input/output error
ntfs_attr_open failed, inode 0 attr 0x10: Input/output error
Inode is corrupt (0): Input/output error
Failed to open ntfs attribute: Input/output error
Failed to load $MFT: Input/output error

Et c'est pareil pour 128 ou 256, par ex.

Pour 32, ntfsck tourne dans le vide apparemment (les disques finissent par se mettre en veille au bout de quelques minutes).

sudo ntfsck /dev/md0

Loading $MFT runlist failed. Trying $MFTMirr.
First attribute must be after the header (0).
^C


Du coup, j'ai l'impression que c'est mal parti pour récupérer quelque chose, non ?

Est-ce que ceci signifie quelque chose ?

sudo mdadm --examine /dev/md0

/dev/md0:
   MBR Magic : aa55
Partition[0] :   1701990410 sectors at    218129509 (type 72)
Partition[1] :    543974724 sectors at    729050177 (type 74)
Partition[3] :        51635 sectors at   2692939776 (type 00)

En ligne

#8 17-09-2017 13:43:31

raleur
Membre
Inscription : 03-10-2014

Re : Récupération de données WD MyBook

Relis bien les commandes que j'ai indiquées. C'est la partition /dev/md0p1 qui contient le système de fichiers, pas l'ensemble RAID /dev/md0.

--examine s'applique aux membres d'un ensemble RAID, pas à un ensemble RAID. Pour afficher des informations sur un ensemble RAID, il faut utiliser --detail. Si on applique --examine à n'importe que type de périphérique, il recherche la présence de méta-données RAID, et à défaut, d'une table de partition. Il trouve bien une signature de MBR, mais le contenu de la table de partition qu'il affiche ne correspond pas du tout à ce qu'avait affiché fdisk sur /dev/sdh. Que contient /proc/partitions ?

Il vaut mieux montrer que raconter.

Hors ligne

#9 17-09-2017 14:03:51

dejieres
Membre
Lieu : Moselle
Distrib. : Bookworm 64 bits
(G)UI : GNOME
Inscription : 07-02-2017

Re : Récupération de données WD MyBook

Oui, je me doutais bien que la dernière commande faisait surgir des fantômes.

J'ai refait, pour être sûr, mais le résultat est le même :

sudo mdadm --build -v /dev/md0 --level=0 --raid-devices=2 --chunk=64 /dev/sdh /dev/sdg

mdadm: array /dev/md0 built and started.

sudo mdadm --readonly /dev/md0

cat /proc/partitions

major minor  #blocks  name

   2        0          4 fd0
   8        0   62522712 sda
   8        1   62521484 sda1
   8       16  488386584 sdb
   8       17          1 sdb1
   8       21   15624192 sdb5
   8       22    3905536 sdb6
   8       23     975872 sdb7
   8       24    4002816 sdb8
   8       25  463872000 sdb9
  11        0    1048575 sr0
  11        1    1048575 sr1
   8       96  976762584 sdg
   8      112  976762584 sdh
   8      113  976762552 sdh1
   9        0 1953525120 md0
 259        1 1953512001 md0p1

sudo ntfsck /dev/md0p1

Loading $MFT runlist failed. Trying $MFTMirr.
file record corrupted at offset 1000198144000 (0xe8e0748000).
Loading $MFTMirr runlist failed too. Aborting.
Inode is corrupt (0): Input/output error
ntfs_attr_open failed, inode 0 attr 0x10: Input/output error
Inode is corrupt (0): Input/output error
Failed to open ntfs attribute: Input/output error
Failed to load $MFT: Input/output error



Est-ce que la carte contrôleur SATA-USB peut éventuellement empêcher quelque chose de fonctionner correctement ? Si oui, je peux refaire les manips en branchant les disques directement en SATA (le temps de remettre un vieux PC en route).

En ligne

#10 17-09-2017 14:16:04

raleur
Membre
Inscription : 03-10-2014

Re : Récupération de données WD MyBook

A priori non, du moment que la capacité des disques est correctement reconnue, ce qui semble être le cas.
Et la taille de la partition /dev/md0p1 dans /proc/partitions (donc reconnue par le noyau) correspond bien à celle affichée par fdisk.
Autrement les ponts USB-SATA peuvent juste bloquer des fonctionnalités ATA spéciales comme SMART.

Tu es sûr que le volume était formaté en NTFS ? Tu ne l'aurais pas reformaté en ext pour l'utiliser avec Linux ?
Tu peux essayer d'identifier le contenu de la partition avec des commandes comme

file -s /dev/md0p1
wipefs /dev/md0p1
blkid /dev/md0p1


Il vaut mieux montrer que raconter.

Hors ligne

#11 17-09-2017 14:31:51

dejieres
Membre
Lieu : Moselle
Distrib. : Bookworm 64 bits
(G)UI : GNOME
Inscription : 07-02-2017

Re : Récupération de données WD MyBook

sudo file -s /dev/md0p1

/dev/md0p1: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS    ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 63, dos < 4.0 BootSector (0x80), FAT (1Y bit by descriptor); NTFS, sectors/track 63, sectors 3907024001, $MFT start cluster 786432, $MFTMirror start cluster 244189000, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 0ec3418be34188da8

sudo wipefs /dev/md0p1

offset               type
----------------------------------------------------------------
0x3                  ntfs   [filesystem]
                     UUID:  EC3418BE34188DA8

sudo blkid /dev/md0p1

/dev/md0p1: UUID="EC3418BE34188DA8" TYPE="ntfs" PARTUUID="df837143-01"


Ça semble bien être du NTFS.

En ligne

#12 17-09-2017 14:42:14

raleur
Membre
Inscription : 03-10-2014

Re : Récupération de données WD MyBook

Alors essaie de monter la partition, tu verras bien.

Il vaut mieux montrer que raconter.

Hors ligne

#13 17-09-2017 15:17:36

dejieres
Membre
Lieu : Moselle
Distrib. : Bookworm 64 bits
(G)UI : GNOME
Inscription : 07-02-2017

Re : Récupération de données WD MyBook

sudo mount -r /dev/md0p1 /mnt

Inode is corrupt (0): Erreur d'entrée/sortie
ntfs_attr_open failed, inode 0 attr 0x10: Erreur d'entrée/sortie
Inode is corrupt (0): Erreur d'entrée/sortie
Failed to open ntfs attribute: Erreur d'entrée/sortie
Failed to load $MFT: Erreur d'entrée/sortie
Failed to mount '/dev/md0p1': Erreur d'entrée/sortie
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.


Ça sent le sapin neutral

En ligne

#14 17-09-2017 20:52:21

raleur
Membre
Inscription : 03-10-2014

Re : Récupération de données WD MyBook

D'après mes tests, blkid et wipefs détectent le système de fichiers NTFS seulement si la taille de chunk est bonne. Si ça ne suffit pas, je n'ai rien d'autre à proposer, désolé.

Il vaut mieux montrer que raconter.

Hors ligne

#15 18-09-2017 07:09:40

dejieres
Membre
Lieu : Moselle
Distrib. : Bookworm 64 bits
(G)UI : GNOME
Inscription : 07-02-2017

Re : Récupération de données WD MyBook

C'est pas grave. J'essaierai de le torturer encore un peu le week-end prochain. Si ça ne donne rien, il passera par la case reformatage.

Merci pour le temps passé là-dessus smile

En ligne

Pied de page des forums