[Logo]
[Titre]

[Retour]

Récupération de disque RAID

J’ai un ami qui avait acheté un tout petit boîtier NAS, un de ces boîtier qui dispose de deux disques dur que l’on peut configurer en RAID 0 ou 1 et qui tient dans la main.

Ça ne fait pas un an qu’il l’utilise pour stocker tout un tas de truc comme des photos et des films. Et puis ce matin, patatrac, le disque démarre mais il ne peut plus se connecter dessus…

Modèle de NAS : Buffalo LinkStation Mini.

Buffalo LinkStation Mini
www.buffalotech.com – linkstation-mini

Pas de signe extérieur de panne, le voyant vert clignote aléatoirement, le voyant bleu est fixe, et l’autre voyant est éteint. Donc il semble tourner normalement.

Vu du partage réseau, on voit le NAS, on y accède, mais impossible de rentrer dans un des partages. L’interface web est accessible mais impossible de se connecter dessus, le compte admin est refusé.

C’est bizarre, on dirait une perte de disque mais il boîtier semble malgré tout démarrer. Et puis avec des disques en RAID1 (mirroring), on devrait avoir quand même accès aux données aussi…

je démonte le boîtier. Il n’est pas prévu pour être démonté. Retire les disques et en met un dans un boîtier externe pour disques durs 2 »5. Le premier disque est visiblement lisible. Pareil avec le deuxième disque qui semble lui aussi lisible. Ou est donc le problème alors?

En essayant de récupérer les précieuses données de l’un des disques, je tombe sur un autre problème. Il y a 6 partitions. J’accède bien au deux première partitions, la première en ext3 qui ressemble à une partition de boot, et la deuxième en xfs qui accueille une racine type Unix. La cinquième partition c’est le swap. Et la sixième qui dispose de la plus grande partie de l’espace disque doit contenir les données, mais impossible d’y accéder. Pour les deux premières, on fait un mount en forçant le type ext3 ou xfs, mais ça ne marche pas sur la dernière partition.

En passant par la commande mdadm, il y a 3 partitions de type RAID reconnues en RAID1, et une non reconnue!?

Elle doit être en RAID0, les données sont réparties sur les deux disques… Impossible donc de récupérer les données à partir d’un seul disque. Et je n’ai qu’un boîtier seul pour disque dur externe 2 »5.

Ce NAS semble tourner avec un Unix. En regardant de près, c’est un Linux en fait, pour ARM, et il dispose d’un serveur ssh.

Sur les deux disques, je pose ma clé public ssh dans root/.ssh/authorized_keys, je décommente dans le fichier /etc/ssh/sshd_config la ligne « AuthorizedKeysFile .ssh/authorized_keys ». Je remonte les disque dans le NAS et le rebranche.

Au démarrage, la connexion en ssh marche tout de suite. Je suis en root sur le NAS!

Dans les logs, le Linux marque qu’il trouve différents volumes RAID (md0 md1 md10 md2) mais qu’il ne peut pas monter le volume /dev/md2 en xfs (error 5). A la main, ça ne marche pas non plus.

Je passe par l’outil xfs_repair pour réparer cette partition en RAID0. Ca marche, tout est là!
C’est repartit!!!

Une recherche un peu plus approfondie dans les logs montre qu’une configuration physiques des disques ne passent pas, le barriers=on. CF référence 1. Pas de trace du crash dans les logs, le Linux n’a pas pu écrire sur les disques à ce moment là bien qu’il était encore « vivant » vu du réseau.

Bref, intéressant d’avoir ce Linux facilement modifiable sous la main, mais ce boîtier NAS ne semble pas avoir un matériel d’une grande fiabilité…

Références :
1) xfs FAQ – What is the problem with the write cache on journaled filesystems?

Tags: , , , ,

Comments are closed.