Récupération des données d’un disque dur chiffré LUKS endommagé

Mon disque dur principal de données a crashé : erreurs d’E/S qui empêchaient de le monter. Son contenu était chiffré avec LUKS/dm-crypt.

J’ai fini par tout récupérer après quelques tâtonnements et, probablement, un peu de chance.

Sommaire

Symptôme : des « I/O error » dans la log du kernel, et un disque dur qui refuse d’être monté. Panique à bord : j’ai perdu toute mes données! (enfin, pas tant que ça, tout l’important était sauvegardé à plusieurs endroits)

Le disque dur ne faisait pas de bruit suspect, laissant penser qu’il ne s’agissait pas d’un gros problème mécanique.

Ouverture LUKS et tentative de réparation

Par chance, l’entête LUKS était accessible, j’ai donc pu passer la première étape indispensable : pouvoir déchiffrer la partition.

2 manières de le faire : via l’application « Disques », ou en ligne de commande :

sudo cryptsetup luksOpen /dev/sdxx recup

Mais ensuite, si j’essaie de monter la partition :

sudo mount /dev/mapper/recup /mnt/recup

Des « I/O Error » dans la log du kernel, et le message d’erreur :

mount: /mnt/recup : wrong fs type, bad option, bad superblock on /dev/mapper/recup, missing codepage or helper program, or other error.

J’ai tenté un fsck :

sudo fsck /dev/mapper/recup

Mais rien à faire :

fsck de util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
fsck.ext4: La tentative de lecture d'un bloc depuis le système de fichiers a produit une lecture tronquée lors de la tentative d'ouverture de /dev/mapper/recup
Peut-être cette partition est-elle de taille zéro ?

Entre-temps, j’ai racheté un gros disque dur (plus gros que celui qui venait de crasher).

Copie des données sur un autre disque

Puisque l’entête LUKS était lisible, je me suis dit qu’il était probable que d’autres données le soient.

J’ai donc fait une copie de la partition déchiffrée :

sudo dd if=/dev/mapper/recup of=/mnt/gros_disque/image_recup.img bs=4096 conv=sync,noerror status=progress

Notez bien les options « conv » : elles sont très importantes :

  • L’option noerror est nécessaire pour que la copie ne s’arrête pas à la première erreur
  • L’option sync est nécessaire pour que dd remplace les données illisibles par des zéros (plutôt que les sauter)

La première fois, j’avais fait la copie sans l’option sync, et la suite n’avait pas bien marché du tout (parce que les offsets sur le disque étaient complètement désalignés).

Réparation du filesystem

Bref, une fois la copie faite correctement, on peut faire le fsck :

sudo fsck -v /mnt/gros_disque/image_recup.img

Il m’a trouvé quelques erreurs, qu’il a essayé de corriger.

Et finalement :

sudo mount /mnt/gros_disque/image_recup.img /mnt/recup/

Et tada! Toutes les données sont là (il est probable que quelques fichiers soient corrompus, mais je ne suis pas encore tombé dessus)

Réutilisation du disque

Plutôt que de jeter le disque, je l’ai reformaté. Comme mes secteurs défectueux sont a priori en début de disque, j’y ai créé une petite partition inutilisée, et ai mis une partition de données sur tout le reste.

Pour être sûr qu’il n’y a pas de secteur défectueux sur cette partition, on peut lancer :

sudo mkfs.ext4 -c -c /dev/mapper/nouvelle_partition

Même si ce disque n’est plus très fiable, il peut encore servir.

Conclusions

Les sauvegardes restent toujours le meilleur moyen de se préserver de ce genre de mésaventures.

Mais, si le disque dur fonctionne encore (mécaniquement), il est probable que seuls certains secteurs soient défectueux. Et le filesystem ext4 est vraiment résiliant : probablement que je peux remercier la redondance des superblocks.

Dernière chose : mon entête LUKS n’était pas corrompue. Si ça avait été le cas, je n’aurais pas pu faire tout ça SAUF si j’avais fait une sauvegarde de cette entête (et c’était bien le cas!). Pour faire cette sauvegarde :

sudo cryptsetup luksHeaderBackup --header-backup-file luksHeaderBackup-nom_device_partition /dev/nom_device_partition

Dans ce cas, j’aurais (a priori) pu faire une image avec dd de la partition chiffrée, puis remettre l’entête luks sur l’image, pour la déchiffrer ensuite. Mais je n’ai jamais eu l’occasion d’essayer (tant mieux!)

4 réflexions sur « Récupération des données d’un disque dur chiffré LUKS endommagé »

  1. Bonjour,

    Merci pour votre tutoriel relatif à la réparation et la récupération d’une partition EXT4 chiffrée en LUKS. J’ai, tenté d’effectuer une récupération de ma partition chiffrée sur ma clé USB (qui a craché lors du démontage), en suivant votre méthode. En effectuant la commande fsck /dev/mapper/recovery, le logiciel me renvoit ce message suivant :


    fsck /dev/mapper/recovery
    fsck from util-linux 2.33.1
    e2fsck 1.44.5 (15-Dec-2018)
    fsck.ext2: Input/output error while trying to open /dev/mapper/recovery

    The superblock could not be read or does not describe a valid ext2/ext3/ext4
    filesystem. If the device is valid and it really contains an ext2/ext3/ext4
    filesystem (and not swap or ufs or something else), then the superblock
    is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193
    or
    e2fsck -b 32768

    En tentant les commandes proposés par le message, j’ai deux messages qui blockent :

    sudo e2fsck -b 8193 /dev/sdc1
    e2fsck 1.44.5 (15-Dec-2018)
    e2fsck: No such file or directory while trying to open /dev/sdc1
    Possibly non-existent device?


    e2fsck -b 32768 /dev/sdc1
    e2fsck 1.44.5 (15-Dec-2018)
    e2fsck: No such file or directory while trying to open /dev/sdc1
    Possibly non-existent device?

    À cause du problème d’accès au superblock, il m’est impossible de pouvoir même à sauver la partition dans un fichier IMG pour pouvoir récupérer mes données inacessibles. Aurait-il une solution à ce problème ?

    1. C’est difficile de faire un diagnostic à distance. D’autant qu’il peut y avoir des tas de contextes différents.
      Dans le cas que j’avais eu, c’était un disque dur classique (avec disques magnétiques), pas une clé USB (à base de mémoire flash). Et seules certaines zones du disque étaient corrompues.

      Si le cryptsetup luksOpen a fonctionné, il y a de l’espoir, et la copie sur un fichier .img devrait fonctionner (quitte à ce qu’elle prenne du temps, et n’arrive pas à lire certaines parties).
      Mais attention à ne pas se tromper de device : les fsck sur /dev/sdc1 n’ont aucune chance de marcher par exemple.
      Dans tous les cas, je conseille de faire la copie sur un fichier .img (avec dd) en premier lieu, puis de faire une sauvegarde de ce fichier .img, et travailler dessus (et non plus directement sur la clé USB). En cas d’erreur de manip, on peut toujours reprendre la sauvegarde du .img, alors qu’on ne pourra pas revenir en arrière sur la clé USB.

      1. Finalement, en suivant votre avis, après avoir effectué un cryptsetup luksOpen, j’ai réussi à récupérer toutes les données de ma clé USB à l’aide de TestDisk, un outil en ligne de commande pour la récupération des données, qui a créé un backup de ma partition LUKS dans un fichier image.dd, et à l’aide de cryptsetup, le tour est joué (ouf !).

        Malheureusemet, ma clé USB, qui est une SanDisk Ultra 16Go, ne répond plus à cause des erreurs I/O (Imput/Output). Mais je pense qu’elle peut être réparée à l’aide d’une application spécialisée dans ce domaine. En attendant, j’ai mis mes données en sécurité (factures, CV, relevés bancaires…). Comme quoi il faut attendre la fin des écritures avant de débrancher la clé (unpluggin), mais mon navigateur de fichier Nautilus avait planté à ce moment précis…

        Votre poste relatif à la récupération d’une partition LUKS m’a été utile. Merci à vous Mossroy!

  2. Bonjour,
    Merci & bravo pour ce partage très utile et clair.
    C’est ainsi que nous bâtissons un Web meilleur, tous ensemble.
    Que La Force soit toujours avec vous !
    Bibi

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *