Ça sent le fichier par ici...

Hello,

Je tenais à partager une aventure amusante. Cette aventure concerne un serveur Proliant MicroServer N40L, un matériel vénérable d'une autre décennie, ressemblant un peu à une mini chaîne hifi des années 90, contenant une baie de 4 disques SATA 3,5 pouces, qui m'a été vendu par un collègue avec les 4 disques de 4 To. Les disques ont pas mal de bouteille mais les chiffres donnés par l'inspection SMART sont excellents. Du matériel idéal pour un NAS de secours.

Mon premier travail est d'ajouter un petit disque dur supplémentaire à l'emplacement prévu pour le lecteur CD/DVD afin d'y installer le système d'exploitation que je souhaite indépendant du support des données. Il existe pour ça des adaptateurs pour installer votre disque dur de façon stable.

Cela fait je souhaite m'occuper des disques destinés au RAID5 et je décide pour ça de partir sur un partitionnement GPT contenant une unique partition. Je lance donc fdisk et je constate qu'il existe déjà un paritionnement GPT, sans aucune partition cependant. Tiens, c'est marrant. Mais je ne pose pas plus de question à ce moment et je crée une première partition. Et là, fdisk m'alerte :

Partition #1 contains an ext4 signature.

Do you want to remove the signature? [Y]es/[N]o:

Tiens tiens tiens, une partition cachée. Je répond donc N et par curiosité je monte la partition sans aucune difficulté. Là je trouve des noyaux Linux et des initramfs, j'ai donc affaire ici à une partition de boot.

Puis je me pose la question : Vais-je trouver les autres partitions qui se cachent sur ces disque ? Vais-je réussir à remonter le RAID qui dort ?

Je me tourne donc vers l'outil testdisk précisément conçu pour ce genre de travail. L'analyse de chaque disque révèle les partitions oubliées. Mon attention se porte particulièrement sur les partitions de type "RAID". Sur chacun des disques je sélectionne la partition en question et testdisk me propose de les inscrire dans le GPT. Je suis allé trop loin pour refuser une telle proposition. Je me retrouve donc avec 4 disques contenant chacun une partition RAID, parfaitement lisible.

Ma curiosité tourne désormais à l'excitation et j'essaye de monter le RAID à l'aide de mdadm.

mdadm --assemble --scan

Premier essai infructueux, message obscur. Je regarde la sortie de dmesg et constate ceci :

md: sdc1 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
md: sdd1 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
md: sde1 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
md: sdb1 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22

Après un peu de recherche, je comprend que quelques métadonnées sont inexploitables (j'ignore la raison) mais peuvent être réparées sans problème, j'exécute donc :

mdadm --assemble /dev/md/debian:1  /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 --force --update=devicesize

Et bim ! Le RAID est ressuscité et j'accède à toutes les données. Je dis bien toutes : photos personnelles, informations bancaires, résultats médicaux entre autres. Et tout ça sans grande expertise en stockage !

Je n'ai bien entendu pas exploité ces données. J'ai juste prévenu le collègue qu'à l'avenir il ferait mieux de prendre le temps d'effacer ses données plus consciencieusement.

Que faut-il en retenir ? Avec l'inflation et l'augmentation des prix, le marché de l'occasion a tendance à fleurir et c'est une bonne chose ; cependant ce genre de situation est appelé à se reproduire. Il est important que chaque personne cédant du matériel stockant de l'information prenne conscience du risque de fuite de données personnelles, et donc prenne le temps d'apprendre à les effacer efficacement avant de se séparer de ce matériel.