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).


L'icône rouge permet de télécharger chaque page du wiki visitée au format PDF et la grise au format ODT → ODT PDF Export

Ceci est une ancienne révision du document !


Récupération de données d'un disque dur endommagé

Introduction

Aïe ! plus moyen de “booter” le système, et/ou plus aucun accès à cette partition de données dont j'ai tant besoin…

Les accès à certaines partitions de ce disque sont impossibles.
Ce disque est-il en train de “mourir” ? (voir avec smartmontools).
Dans le doute, il va falloir le manipuler le moins possible pour l'empêcher d'aggraver lui-même sa situation.

Donc, la première des choses à faire, c'est de créer un copie brute de ce disque sous la forme d'un fichier image disque.
Ensuite, on pourra prendre tout son temps pour tenter tout ce qui est possible avec le fichier, pendant que le disque original attendra sagement dans son coin.

Pour créer ce fichier de copie image disque, plusieurs outils existent avec chacun leur avantages et inconvénients.
Ici, l'image disque a été crée avec whdd.

Bientôt ici, 3 nouveaux liens vers les tutos :
Création image disque avec dd, avec GNU-ddrescue et avec whdd.

Installation

Il va être indispensable d'obtenir un accès à ces partitions défectueuses afin de pouvoir tenter de réparer leur système de fichiers.
Mais tant que le système de fichier est incohérent, “mount” ne peut rien faire d'autre que de signaler ces erreurs.

Pour obtenir cet accès, il existe une méthode qui consiste à “mapper” ce disque avec le programme kpartx.
Grâce à kpartx le système verra le fichier image disque comme s'il s'agissait d'un disque physique connecté à la machine.
Il sera alors possible de tenter de corriger les incohérences qui rendent ces partitions inaccessibles.

Installons kpartx, après, bien sûr, avoir mis à jour la liste des paquetages :

apt-get update && apt-get install kpartx

L'état des lieux

whdd-copy-mode est le fichier image récupéré par copie (grâce à WHDD) du disque “mourant”.

Voyons ce que nous dit fdisk sur ce fichier image disque :

fdisk -l whdd-copy-mode
retour de la commande
Disk whdd-copy-mode: 37.3 GiB, 40020664320 bytes, 78165360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xace22e9e
 
Device          Boot  Start     End      Blocks    Id System
whdd-copy-mode1       57993214  78163967 10085377   5 Extended
whdd-copy-mode2           2048  16386047  8192000  83 Linux
whdd-copy-mode3 *     16386048  30726143  7170048  83 Linux
whdd-copy-mode4       30726144  57991167 13632512  83 Linux
whdd-copy-mode5       57993216  64342015  3174400  82 Linux swap / Solaris
whdd-copy-mode6       64344064  78163967  6909952  83 Linux
 
 Partition table entries are not in disk order.

Préparation

Association et "mappage"

On va associer ce fichier image disque au périphérique /dev/loop0 :

losetup /dev/loop0 whdd-copy-mode

Pour permettre l'accès aux partitions du fichier image disque whdd-copy-mode,
on va utiliser kpartx pour faire une “projection” (mappage) de ses partitions sur le périphérique /dev/mapper:

kpartx -a whdd-copy-mode

Examinons ce que ça a donné en listant le répertoire /dev/mapper :

ls -l /dev/mapper/
retour de la commande
total 0
crw------- 1 root root 10, 236  1 janv. 20:52 control
lrwxrwxrwx 1 root root       7  1 janv. 20:52 loop0p1 -> ../dm-0
lrwxrwxrwx 1 root root       7  1 janv. 20:52 loop0p2 -> ../dm-1
lrwxrwxrwx 1 root root       7  1 janv. 20:52 loop0p3 -> ../dm-2
lrwxrwxrwx 1 root root       7  1 janv. 20:52 loop0p4 -> ../dm-3
lrwxrwxrwx 1 root root       7  1 janv. 20:52 loop0p5 -> ../dm-4
lrwxrwxrwx 1 root root       7  1 janv. 20:52 loop0p6 -> ../dm-5

Le "mountage"

Créons les 6 répertoires qui vont servir de points de “mountage” pour ces partitions.

mkdir -p /mnt/sdc/sdc{1,2,3,4,5,6}

Vérifions qu'ils ont bien été créés :

ls -l /mnt/sdc/
retour de la commande
/mnt/sdc/:
total 24
drwxr-xr-x 2 root root 4096  1 janv. 21:01 sdc1
drwxr-xr-x 2 root root 4096  1 janv. 21:01 sdc2
drwxr-xr-x 2 root root 4096  1 janv. 21:01 sdc3
drwxr-xr-x 2 root root 4096  1 janv. 21:01 sdc4
drwxr-xr-x 2 root root 4096  1 janv. 21:01 sdc5
drwxr-xr-x 2 root root 4096  1 janv. 21:01 sdc6

Il nous faut maintenant mounter ces partitions sur les points de “mountage” précédemment créés:

mount /dev/mapper/loop0p1 /mnt/sdc/sdc1
retour de la commande
mount: wrong fs type, bad option, bad superblock on /dev/mapper/loop0p1,
missing codepage or helper program, or other error
 
In some cases useful info is found in syslog - try
dmesg | tail or so.

/dev/mapper/loop0p1 corresponds à une partition de type Étendue (conteneur de partitions “logiques”).
Le message d'erreur wrong fs type suite à l'exécution de la commande mount est donc tout à fait normal.

mount /dev/mapper/loop0p2 /mnt/sdc/sdc2
mount /dev/mapper/loop0p3 /mnt/sdc/sdc3
mount /dev/mapper/loop0p4 /mnt/sdc/sdc4
retour de la commande
mount: wrong fs type, bad option, bad superblock on /dev/mapper/loop0p4,
missing codepage or helper program, or other error
 
In some cases useful info is found in syslog - try
dmesg | tail or so.
mount /dev/mapper/loop0p5 /mnt/sdc/sdc5
retour de la commande
mount: unknown filesystem type 'swap'

loop0p5 correspond à une partition de type swap, le message d'erreur est donc tout à fait normal.

mount /dev/mapper/loop0p6 /mnt/sdc/sdc6

Les partitions “mountées” sur sdc2, sdc3, et sdc6 ont été “mountées” sans problème.
Leur contenu est donc maintenant accessible.

La réparation

Où en est-on ?

Les deux partitions que nous allons tenter de réparer sont donc :
sdc1loop0p1
sdc4loop0p4

Étant donné que la première partition est une partition de type Étendue,
et que cette partition n'est qu'un conteneur de partitions de type Logique,
il n'y a aucun système de fichiers à réparer sur cette partition.

Par contre la deuxième peut-être réparée avec fsck.ext4.

De toutes façons, une seule partition nécessite une vérification et si besoin une réparation,
comme on peut le constater avec fdisk -l.

fdisk -l whdd-copy-mode
retour de la commande
Disk whdd-copy-mode: 37.3 GiB, 40020664320 bytes, 78165360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xace22e9e
 
Device          Boot  Start     End      Blocks    Id System
whdd-copy-mode1       57993214  78163967 10085377   5 Extended
whdd-copy-mode2           2048  16386047  8192000  83 Linux
whdd-copy-mode3 *     16386048  30726143  7170048  83 Linux
whdd-copy-mode4       30726144  57991167 13632512  83 Linux
whdd-copy-mode5       57993216  64342015  3174400  82 Linux swap / Solaris
whdd-copy-mode6       64344064  78163967  6909952  83 Linux
 
 Partition table entries are not in disk order.

En douceur

On va d'abord commencer par n'utiliser fsck qu'avec l'option -n qui ne travaille qu'en mode lecture et n'affichera seulement que les erreurs qu'il faudrait corriger.

fsck.ext4 -n /dev/mapper/loop0p4

Le retour de cette dernière commande est bien trop long pour être affiché ici.
En voici une copie (fichier texte) : fsck.txt

Et maintenant, au boulot !

fsck.ext4 -f -y /dev/mapper/loop0p4
... (beaucoup de messages)

On va vérifier ce que ça donne maintenant :
en utilisant more (histoire de rien perdre des éventuels messages qui s'afficheraient…)

fsck.ext4 -n /dev/mapper/loop0p4 | more
retour de la commande
e2fsck 1.42.8 (20-Jun-2013)
home-buntu : propre, 234476/848640 fichiers, 2178724/3407872 blocs

(propre ⇒ mais…il annonce que la partition est réparée!).

Vérification

Dernière vérification : “mounter” et lister le contenu de la partition réparée.

mount loop0p4 /mnt/sdc/sdc4/ && ls -l /mnt/sdc/sdc4/

L'Ode à la joie

Tout est là! \o/!

Toutes mes partitions sont réparées. Hourra!

Dé-mountage

Libération du périphérique /dev/loop0 (dé-mappage de ses partitions).

kpartx -d /dev/loop0

Détacher le fichier image disque whdd-copy-mode associé au périphérique boucle /dev/loop0.

losetup -d /dev/loop0

Destruction des points de “mountage” et du répertoire les contenant.

rm -r /mnt/sdc

Restauration

Recopie de l'image sur le disque

connexion et identification du disque

Le fichier image disque étant maintenant détaché du périphérique /dev/loop0, Il suffit de le recopier sur le périphérique physique par son point de mountage au système. Pour cela, whdd ou plus simplement dd peuvent êtres utilisés.

N'ayant pas encore de disques disponibles pour faire de vrais tests (je les reçoit dans une semaine…), ni installé wgdd, je ne présenterais que la méthode utilisant dd.
Je vais supposer que, comme le disque était “malade”, il avait été déconnecté physiquement de la machine le temps d'effectuer les manipulations précédentes.

1°/ Cas du disque dans un boîtier USB ou SATA connecté à chaud. Avant de connecter physiquement le disque physique à la machine,
ouvrez une fenêtre de terminal, connectez vous sous le compte du super-utilisateur root, et entrez la commande suivante :

tail -f -n 5 /var/log/messages
retour de la commande
Jan  9 06:31:24 deb-G53SW mtp-probe: bus: 3, device: 19 was not an MTP device
Jan  9 06:31:24 deb-G53SW mtp-probe: bus: 3, device: 18 was not an MTP device
Jan  9 06:31:25 deb-G53SW kernel: [ 4074.562535] usblp1: removed
Jan  9 06:31:25 deb-G53SW kernel: [ 4074.569289] usblp1: USB Bidirectional printer dev 19 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0027
Jan  9 06:31:25 deb-G53SW udev-configure-printer: Re-enabled printer ipp://localhost:631/printers/HL-2030-series

Connectez physiquement le disque à la machine et observez les nouveaux messages qui apparaissent dans la fenêtre de terminal.

En cours d'édition : je referai plus tard les fenêtres de retour de commandes avec un disque comportant les mêmes partitions. \\
messages
Jan  9 06:58:27 deb-G53SW kernel: [ 5696.507982] sd 9:0:0:0: Attached scsi generic sg4 type 0
Jan  9 06:58:27 deb-G53SW kernel: [ 5696.508454] sd 9:0:0:0: [sdd] 625142448 512-byte logical blocks: (320 GB/298 GiB)
Jan  9 06:58:27 deb-G53SW kernel: [ 5696.508844] sd 9:0:0:0: [sdd] Write Protect is off
Jan  9 06:58:28 deb-G53SW kernel: [ 5696.707204]  sdd: sdd1 sdd2 < sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12 sdd13 sdd14 sdd15 sdd16 >
Jan  9 06:58:28 deb-G53SW kernel: [ 5696.711281] sd 9:0:0:0: [sdd] Attached SCSI disk

Suite à la détection par le noyau de la connexion d'un nouveau périphérique, 4 nouvelles lignes sont apparues dans la fenêtre de terminal. La dernière ligne nous permet de constater que le fichier de périphérique /dev/sdc a été associé au disque nouvellement connecté. On peut maintenant stopper l'exécution de la commande tail avec Ctrl-c.

On peut s'assurer qu'il s'agit bien de notre disque en visualisant ses références avec la commande suivante:

ls -l /dev/disk/by-id | grep sdd$
retour de la commande
lrwxrwxrwx 1 root root  9 janv.  9 06:58 usb-ST932042_3AS_088810000000-0:0 -> ../../sdd

Et confirmer le fait en visualisant l' UUID de touts les partitions présentes sur ce disque.

ls -l /dev/disk/by-uuid | grep sdd
retour de la commande
lrwxrwxrwx 1 root root 11 janv.  9 06:58 2864c6d8-3e6e-407a-88dd-b5848a9bdbdd -> ../../sdd16
lrwxrwxrwx 1 root root 10 janv.  9 06:58 3214e144-879f-4edd-94fc-11cb85b81472 -> ../../sdd9
lrwxrwxrwx 1 root root 10 janv.  9 06:58 33a9116c-e10f-4e6a-acd8-a90d20cb8e26 -> ../../sdd6
lrwxrwxrwx 1 root root 11 janv.  9 06:58 3df408e9-e65e-4659-9881-84ae6d077c43 -> ../../sdd14
lrwxrwxrwx 1 root root 11 janv.  9 06:58 4d8b7d8f-30db-4637-b33b-84c42df4cd88 -> ../../sdd13
lrwxrwxrwx 1 root root 11 janv.  9 06:58 74349cee-dd8c-4ce5-ab45-a8e7b25cdda0 -> ../../sdd15
lrwxrwxrwx 1 root root 10 janv.  9 06:58 965d9bed-c44b-4920-bf5a-9cae3da537f0 -> ../../sdd1
lrwxrwxrwx 1 root root 11 janv.  9 06:58 9e2ba03c-bada-4db8-a761-fe3093b92860 -> ../../sdd11
lrwxrwxrwx 1 root root 10 janv.  9 06:58 a05f71f5-83f6-46b8-a96a-499129916136 -> ../../sdd8
lrwxrwxrwx 1 root root 10 janv.  9 06:58 a1fdf8ed-cc93-43bb-b37b-7ce8b0b3e153 -> ../../sdd5
lrwxrwxrwx 1 root root 11 janv.  9 06:58 a69d9182-f4c7-4276-b35d-7d5f9bd50a57 -> ../../sdd10
lrwxrwxrwx 1 root root 11 janv.  9 06:58 b9bf96f4-694a-453f-aad6-d84efbb1f299 -> ../../sdd12
lrwxrwxrwx 1 root root 10 janv.  9 06:58 fd63ad30-fc7b-4640-b1ba-10c0da651be9 -> ../../sdd7

Les UUID des partitions correspondent, c'est bien notre disque qui est connecté sur /dev/sdd. Pour que la recopie du fichier image disque puisse être faite, il faut d'abord (au cas où) “dé-mounter” les partitions de ce disque.

umount /dev/sdd*

On vérifie que plus aucune des partitions de ce disque n'est “mountée” sur le système de fichiers:

mount | grep /dev/sdd

Si cette dernière commande n'a rien retourné, on peut lancer la recopie du fichier image disque sur le disque physique.

dd if=whdd-copy-mode of=/dev/sdd bs=1M; sync

Il va falloir patienter en fonction de la “taille” du disque…

1)
N'hésitez pas à y faire part de vos remarques, succès, améliorations ou échecs !
doc/materiel/disques-durs/recuperation-de-donnees-disque-endomage.1389248493.txt.gz · Dernière modification: 09/01/2014 07:21 par MicP

Pied de page des forums

Propulsé par FluxBB