Après avoir ouvert le lecteur réseau et extrait le disque dur dans la première partie, il faut maintenant lire le disque pour récupérer les données.
Pour cela il y a besoin :
- D’un appareil capable de brancher un disque dur PATA. Pour ma part c’est un boîtier de disque dur USB 3.0 pour disques 3 pouces ½. Si vous avez un PC fixe avec une carte mère disposant d’un port PATA et d’une prise d’alimentation Molex libre, ça ira aussi très bien.
- D’un PC fonctionnant avec GNU Linux. A noter que si vous avez Windows 10, WSL (Windows Subsystem Linux) ne fonctionne pas car l’accès aux systèmes de fichiers reste géré par le noyau Windows. Dans ce cas il faut booter sur une clef USB ou un CD avec une image GNU Linux live comme Mageia, Gentoo, System Rescue CD, etc.
- De la place sur un autre disque. Prévoir au moins 180Gio.
- De connaissances sur l’usage de la ligne de commande et de l’adminstration système Unix.
- D’une bonne documentation providentielle.
Pour le dernier point j’ai eu la chance de tomber sur le blog d’OETEL-X, un néerlandais qui a eu le même besoin que moi, et qui a passé le temps nécessaire pour trouver la solution.
Comme indiqué dans le blog d’OETEL-X, le disque a été organisé de manière non standard par Maxtor. La partition qui nous intéresse, celle où sont les données, utilise ReiserFS 3.6. Hélas GNU Linux ne la reconnait pas automatiquement car la table de partitionnement ne l’indique pas.
Toujours est-il que le bon bout, il commence à l’octet 528785408 du disque. Hasard complet ? Non : les disques sont souvent organisés en blocs de taille multiple de 4Kio (soit 4096 octets) et là on est au 64549ème bloc de 8Kio. Et qu’est-ce qu’il y a à cet endroit ? Un petit hexdump des 64Kio + 2Kio donne :
[root@localhost]# hexdump -C -s 528785408 -n 67584 /dev/sdb 1f84a000 42 72 63 6d 53 65 4d 61 67 69 63 53 74 72 00 00 |BrcmSeMagicStr..| 1f84a010 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….| 1f84a020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….| * 1f85a000 a0 b8 f5 02 64 77 51 00 a9 f9 51 01 12 00 00 00 |….dwQ…Q…..| 1f85a010 00 00 00 00 00 20 00 00 00 04 00 00 a9 c2 45 3c |….. ……..E<| 1f85a020 84 03 00 00 1e 00 00 00 00 00 00 00 00 10 cc 03 |…………….| 1f85a030 42 00 01 00 52 65 49 73 45 72 32 46 73 00 00 00 |B…ReIsEr2Fs…|
Le début du bloc comporte la chaîne « BrcmSeMagicStr ». Sur le site de CnW Recovery Software on apprend qu’il s’agit d’un code en début de disque RAID pour Broadcom. Et comme le processeur MIPS du MSS est un Broadcom également, ça se tient.
Plus loin, juste après les 64Kio vides évoqués par OETEL-X on a en hexadécimal « a0 b8 ». C’est peut-être un hasard, mais dans la table des codes de partitions connues de gdisk il y a beaucoup de code commençants par « a0 .. ». Vient enfin le « ReIsEr2Fs » indiqué par OETEL-X.
Pour monter la partition, je reprends la commande indiquée en adaptant à l’emplacement de mon disque /dev/sdb et à mon point de montage /run/ddmss :
# mkdir /run/ddmss # mount -t reiserfs -o loop,offset=528785408 /dev/sdb /run/ddmss
Et là miracle, GNU Linux retrouve ses petits. Et dans dmesg il y a bien des blocs de 8Kio (« size 8192 »).
Il reste a recopier les données. Pour faire d’un coup et trier plus tard j’ai utilisé rsync :
# rsync -av /run/ddmss/ /home/user/save_mss/
A partir de maintenant l’idéal est de sécuriser les données par copie sur un autre appareil (un autre NAS par exemple) avant de formater définitivement le disque dur Maxtor.
Et après, bon courage pour le tri !