Hier, j’ai eu une petite frayeur en constatant qu’un test automatique SMART (long selftest) rencontrait une erreur de lecture sur l’un des disques durs de mon NAS de sauvegarde. Celui-ci apparaissait en SMART rouge sur l’interface OpenMediaVault…

Comme c’est un NAS DIY, je n’ai pas de procédure automatique en cas de panne de disque dur : il faut intervenir à la main. Je pose ici la procédure, pour la partager et m’en souvenir, car quand un disque tombe, les autres vont commencer à faire pareil…

Le disque en panne est /dev/sdb, et je suis dans le cas d’un RAID5 où je peux retirer un disque du RAID, sans perdre de données. Le NAS ne contient que des sauvegardes, donc je peux perdre toutes les données, mais j’aime mieux pas (10 To de sauvegardes à reconstituer pendant plusieurs semaines, mon cœur ne tiendrait pas).

Dans un terminal ouvert sur le NAS en ssh sous root (ssh [email protected]), utilisez les commande suivantes (il faut adapter les commandes selon votre configuration. VOUS DEVEZ COMPRENDRE CHAQUE COMMANDE AVANT DE LA LANCER. Une erreur a pu se glisser dans la suite de commandes que j’indique, je décline toute responsabilité, SGDZ, pas taper) :

Je déclare le disque en panne (SMART ne l’a pas fait), puis je le retire du RAID5 :

mdadm --manage /dev/md0 --fail /dev/sdb
mdadm --manage /dev/md0 --remove /dev/sdb

Je constate dans l’interface OpenMediaVault que le RAID est passé en mode dégradé (il ne l’était pas encore car le problème que j’ai détecté est un problème SMART).

J’arrête le NAS et je remplace hors tension le disque défectueux par un disque de même taille, judicieusement disponible à cette occasion (spare à froid).

Je redémarre le NAS et constate que l’interface OpenMediaVault ne me propose pas d’insérer dans le RAID le nouveau disque dur, sans doute parce que celui-ci n’est pas correctement préparé. Je vais le préparer avec les commandes suivantes :

Je me reconnecte root sur le NAS avec un terminal via ssh, pour lancer la commande gdisk :

gdisk /dev/sdb

Et là, horreur malheur, j’ai les informations suivantes :

GPT fdisk (gdisk) version 1.0.1

Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header.

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended.

Dans l’interface de la commande gdisk, je passe en mode “Expert command” en tapant “x”, puis je supprime les structures GPT et nettoie MBR avec la commande “z”:

Command (? for help): x
Expert command (? for help): z
About to wipe out GPT on /dev/sdb. Proceed? (Y/N): Y

GPT data structures destroyed! You may now partition the disk using fdisk or other utilities.

Blank out MBR? (Y/N): Y

Je quitte gdisk avec la commande “w”, puis je relance gdisk pour vérifier que tout est bon :

# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present

Creating new GPT entries.

Command (? for help): q

J’ajoute enfin le nouveau disque dans la grappe RAID :

mdadm --manage /dev/md0 --add /dev/sdb

Je vérifie qu’il n’y a pas d’erreur bizarre, avec :

fdisk -l  # <-- le signe avant le croisillon est un L minuscule

Je vérifie que le RAID se reconstruit correctement, dans l’interface OpenMediaVault ou avec la commande :

cat /proc/mdstat

Je prie pour qu’aucun autre disque ne lâche dans les heures suivantes…

Une fois tout rentré dans l’ordre, je n’oublie pas de reprogrammer un selftest SMART de type long sur le nouveau disque, dans l’interface OpenMediaVault.

J’espère que ce billet pourra faire gagner du temps à quelques uns.