WHDD est un logiciel libre, écrit par Andrey UTKIN. Clone d’un freeware nommé MHDD, il permet de réaliser diverses opérations sur un disque dur, incluant la récupération de données sur un disque dur endommagé, dans certaines limites.

Son avantage est d’abord qu’il est écrit dans un langage bas niveau, (il s’adresse aux couches logicielles les plus proches du matériel), et ensuite qu’il utilise une stratégie de recherche de données élaborée pour éviter le plus possible d’amener le disque dur testé à chauffer.

On le trouve prêt à l’emploi dans System Rescue CD, ou sous forme de sources sur github: https://github.com/whdd/whdd

Vous y trouverez l’information sur la manière de le compiler. Il nécessite en prérequis le programme dialog, qui bien qu’il ne soit plus développé est encore présent dans les dépôts des distributions GNU/Linux les plus employées (pour ce que j’en sais).

Comment l’utiliser

WHDD

D’abord, installer et lancer WHDD, soit depuis une distribution qui le fournit, comme SystemRescueCD, soit en le cherchant dans le dépôt de votre distribution, ou en le compilant depuis les sources.

Ensuite, regardez cette vidéo.
https://orditux.org/Downloads/whdd.webm
(elle est un peu trop rapide).
Plus de démos ici : https://whdd.github.io/demo/

Pensez à l’espace requis : il est nécessaire d’avoir un disque destination  ou une partition destination de volume égal ou supérieur au disque source entier. La raison en est que le clone ne peut pas être compressé par l’outil WHDD lors de la recherche des secteurs à sauvegarder. Donc, c’est tout, ou rien.

Il vous faudra aussi être patient, la création de l’image peut prendre plusieurs heures. Il m’est arrivé de lancer une opération de sauvetage en fin de journée un été, et d’installer un ventilateur en face du disque dur à sauver, pendu au bout du câble SATA avant de quitter le local, (pour ne pas enfermer le disque dur avec les données à sauver, et pour prévenir une chauffe trop importante du disque). J’ai pu récupérer l’image du disque ainsi traité, le lendemain matin.

Traiter l’image obtenue

Toutes les commandes sont lancées avec les droits root :

# losetup /dev/loop0 whdd-copy-mode  // où whdd-copy-mode est le fichier extrait du disque mourant /dev/sdc avec WHDD.

* Installation de multipath-tools qui contient kpartx ;

# kpartx -a whdd-copy-mode // modifier le nom de l'image selon le nom utilisé

Ce qui a permis d’accéder aux partitions de l’image disque whdd-copy-mode :

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

Création de répertoires sous /mnt pour monter chaque partition :

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

[root@squirrel mnt]# ls -l sdc/
sdc/:
total 24
drwxr-xr-x 2 root root 4096  1 Jan 21:01 sdc1
drwxr-xr-x 2 root root 4096  1 Jan 21:01 sdc2
drwxr-xr-x 2 root root 4096  1 Jan 21:01 sdc3
drwxr-xr-x 2 root root 4096  1 Jan 21:01 sdc4
drwxr-xr-x 2 root root 4096  1 Jan 21:01 sdc5
drwxr-xr-x 2 root root 4096  1 Jan 21:01 sdc6

Certains périphériques de /dev/mapper ne parviennent pas à être montés :

# mount /dev/mapper/loop0p1 /mnt/sdc/sdc1
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.

# mount /dev/mapper/loop0p2 /mnt/sdc/sdc2
#

# mount /dev/mapper/loop0p3 /mnt/sdc/sdc3
#

# mount /dev/mapper/loop0p4 /mnt/sdc/sdc4
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
mount: unknown filesystem type 'swap'

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

Bien sûr, “loop0p5” est la partition swap, dont nous n’avons pas besoin. Les deux partitions que nous pourrions vouloir réparer sont celles liées à sdc1 (ici loop0p1) et sdc4 (ici loop0p4).

Les partitions liées à sdc2 et sdc6 se montent correctement et leur contenu est accessible.

L’étape suivante consiste à essayer de réparer les 2 partitions qui déclenchent les erreurs avec fsck.ext4. L’utilisation de l’option ‘-n’ en premier (mode lecture seule) montre qu’il y a des erreurs à corriger.

Cependant, une seule partition doit être vérifiée et si possible réparée. Nous pouvons le voir avec “fdisk -l” (lancé en root car le fichier image appartient à root) :

# fdisk -l whdd-copy-mode

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.

La partition numéro 1 est une partition étendue contenant les autres. Par conséquent, l’erreur “wrong fs type” de la commande mount sur /dev/mapper/loop0p1 est normale.

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

# fsck.ext4 -n loop0p4

(Voir le fichier fsck.txt pour le contenu, qui est assez long)
Maintenant, le vrai travail :

# fsck.ext4 -f -y loop0p4

… (nombreux messages)

Terminé :

# fsck.ext4 -n loop0p4 | more
e2fsck 1.42.8 (20-Jun-2013)
home-buntu : propre, 234476/848640 fichiers, 2178724/3407872 blocs

(Le système indique que la partition est propre).

Par conséquent :

# mount loop0p4 /mnt/sdc/sdc4/
# cd /mnt/sdc/sdc4/
# ls -l

Toutes mes données sont là. Hurrah \o/ !

Il ne reste plus qu’à les copier vers un espace permanent:

# rsync -av /mnt/sdc/sdc4/ "/chemin/vers/espace dédié/"

Le tutoriel employé pour réaliser la partie kpartx du sauvetage peut se retrouver sur le wiki de la communauté Debian Facile.

Si ce programme ne garantit pas qu’il vous permette de récupérer les données sur un disque dur endommagé il est cependant très intéressant, du fait qu’il travaille lentement, en cherchant les données méthodiquement, et en cherchant dans un autre secteur à chaque fois qu’il rencontre une erreur. Il évite ainsi de faire trop chauffer le disque dur. En l’utilisant, j’ai pu réussir des sauvetages déjà plusieurs fois, là où par exemple, “dd” avait échoué.

Article vérifié et mis à jour en février 2026