Journal Politique du maintien des blocs et évolution du RAID

Sommaire

• La panne
• C'est quoi un superblock
• Le redémarrage
• La morale

Cher Journal,

Au milieu des avalanches de logiciels à patcher, de mauvaises nouvelles en tout genre et climat légèrement sous tension, j'ai décidé (malgré moi en réalité) de reprendre le contrôle et de devoir réparer un service que j'avais moi même cassé, plutôt que de subir des évènements extérieurs en permanence. C'était une expérience assez intéressante pour moi et je vais donc te la raconter.

Comme toutes les certaines bonnes histoires, l'origine vient de loin. J'ai depuis 2008 un ordinateur qui sert de NAS, avec quatre disques durs. Le matériel a changé depuis, les disques durs ont été progressivement remplacés (plusieurs fois), le système a été complètement réinstallé (sur une autre architecture CPU), mais la grappe RAID est restée au niveau logiciel la même, évoluant au fur et à mesure.

La panne

En 2026, j'ai donc un système RAID 5 logiciel (avec mdadm) de quatre disques (pouvant donc perdre un disque sans tomber en panne) qui date de 2008. Le système de fichier manque également de modernité, avec du EXT3 de l'époque. Je décide de mettre à jour de Debian Bookworm vers Debian Trixie ce beau système (oui, il a été oublié, et j'avais une demi-heure de libre). La mise à jour semble bien se passer, jusqu'au redémarrage : le NAS ne revient pas sur le réseau.

Intrigué je ressors un écran compatible VGA (et oui…) un clavier (l'USB marche, même pas besoin d'aller chercher un PS/2 à la cave) et je regarde ce qui se passe.

Je découvre alors que l'initrd démarre bien, mais ne trouve aucun des systèmes de fichiers qu'il doit monter. Ni le /, ni la partition /home. En regardant dans /proc/mdstat, le noyau n'a trouvé qu'un seul volume RAID (contre deux normalement, un système et un donnée) et ce volume est calculé sur l'intégralité des disques (normalement pourtant sur des partitions séparées). De plus, comme le RAID a été trouvé sur l'intégralité du disque, les partitions ne sont pas visibles dans /dev.

Je trouve cela curieux. Je me dis que c'est un reliquat de configuration d'un temps ancien, et sans trop réfléchir j'écrase les superblocks avec un bon mdadm --zero-superblock /dev/sda (et pareil pour les disques b/c/d). Je me dis qu'il n'y a aucun risque, mes superblocks à moi sont sur les partitions. J'efface donc tout, et je redémarre le système pour un démarrage propre.

C'est quoi un superblock

C'est le moment ou l'histoire a besoin d'un petit détour. Pour savoir comment réassembler les blocs de différents disques et ordonner les données correctement, mdadm qui contrôle le RAID va écrire des métadonnées sur le disque. Ces métadonnées sont critiques : elles contiennent la position du disque sur la grappe (oui c'est important), la taille du fragment (chunk), l'algorithme utilisé pour la répartition des données, et probablement d'autres. J'ai lu qu'ils pouvaient contenir pour les récents des listes de blocs défectueux sur le disque.

Sans ces superblocks, la donnée est toujours présente. Mais pour y accéder, il faut reconstruire à la main exactement la bonne configuration qui permet de lire ces données. Le format des superblocks a évolué avec le temps. Ce qui est important de retenir, c'est que ces superblocks étaient il y a longtemps stockés à la fin de l'équipement, et sur des systèmes moins vieux au début. La documentation notamment signale que stocker à la fin de la partition n'était pas une bonne idée :

Putting the superblock at the end of the device is dangerous if you have any kind of auto-mounting/auto-detection/auto-activation of the raid contents; in some circumstances (in the case of blkid: if the superblock is damaged) the raid components could be detected as a valid filesystem (or other format) which may contain outdated data. This will desynchronise the array and compromise the data

Fin de la petite parenthèse, revenons au récit.

Le redémarrage

Je suis très fier, le système démarre correctement. Je vois les lignes habituelles d'un Linux qui démarre. Jusqu'au moment ou il s'arrête, indiquant ne pas trouver la partition /home. Je ne suis pas inquiet, il a démarré, il doit manquer un petit morceau.

De fil en aiguille je comprends cependant que l'effacement des superblocks a en fait effacé les blocs des partitions de données. C'est « logique », ils sont situés en fin de la dernière partition, donc en fin de disque. Mon vieux RAID utilisait toujours de format 0.9, dangereux, et j'ai donc fait une grosse bêtise.

C'est là ou commence du coup un jeu « amusant ». Je peux retrouver les données à condition de recréer la grappe avec exactement les mêmes options :
- Le même ordre sur les disques (il y en a quatre, soit 24 combinaisons possibles)
- Les mêmes options, notamment la taille des chunks

L'idée est donc de tenter les différentes options en disant à mdadm « si si c'est bien ça » (option --assume-clean). Tenter de monter le système de fichier, et voir si quelque chose de cohérent comme donnée sort.

Je dois vous avouer à ce moment là n'avoir aucune idée de comment retrouver ça. Pour l'ordre des disques, comme le système a démarré, j'ai retrouvé les informations dans les logs noyaux de précédent démarrage réussis (avec un correspondance entre les noms dans /dev et la position dans la grappe. Mais les noms /dev peuvent changer, il a fallu chercher les numéros de séries avec). Cela m'a épargné bien de la peine. Cependant, avec des tailles de chunk par défaut (de 2026) j'avais un système de fichier « bizarre » : bien reconnu comme du ext3, les informations semblaient bonnes, mais impossible de le monter et e2fsck criait très fort. J'ai réussi à trouver sur Internet qu'en 2008 la taille par défaut des chunks étaient de 64KB (et je ne suis pas du genre à changer les options par défaut). J'ai mis l'option sur mon mdadm de 2026 pour forcer à 64KB, et j'ai retrouvé un système environ correct.

Comme je n'avais pas toujours mis l'option --read-only sur l'intégralité de mes tentatives (apparemment, je pensais que si), j'ai cependant endommagé quelques parties (je n'ai pas encore fait l'étude réelle de l'impact, mais il semble limité).

La morale

Je n'ai pas cherché exactement ce qui a changé entre Bookworm et Trixie, mais donc je me suis fait avoir par les superblocks en fin de partition qui ont été considérés comme en fin de disque, construisant une grappe invalide. Ces vielles métadonnées, au format obsolète mais parfaitement fonctionnel, ont été à l'origine des ennuis. Ensuite des manipulations peu prudentes (je ne manipule pas non plus du RAID tous les matins) ont conduit à un état chaotique.

La réparation (avant de tenter d'aller chercher les sauvegardes) a été laborieuse mais intéressante. Je n'avais jamais lancé la grande majorité des commandes que j'ai tenté sur mdadm pour comprendre mon problème. Sachez également qu'il n'est pas forcément facile en 2026 de trouver des informations sur les valeurs par défaut d'un logiciel en 2008. Il y a eu beaucoup de essais-erreurs.

J'ai copié en tout cas toutes les données « ailleurs » et je suis actuellement en train de reconstruire une grappe RAID toute neuve, avec un système de fichiers moderne, et je note dans ma tête de ne pas laisser la prochaine grappe atteindre l'âge adulte avant de la reconstruire.