Pourquoi un ensemble RAID devient-il inactif après une coupure de courant ?

Après une coupure de courant, un ensemble RAID peut rester inactif car ses métadonnées ont été détectées, mais le système n’a pas pu le démarrer en toute sécurité avec les membres et l’état disponibles.

Le terme « inactif » décrit le plus directement les ensembles md sous Linux, bien que d’autres piles de stockage rencontrent des échecs similaires d’importation ou d’activation. Vérifiez la découverte des périphériques, les métadonnées des membres, l’état sale ou dégradé, la configuration de démarrage et les défauts du chemin d’alimentation avant de tenter un démarrage forcé.

Comprendre ce que signifie Inactif dans le RAID Linux

Un ensemble md inactif peut avoir des périphériques et une certaine configuration attachés tout en refusant les E/S normales. Ce n’est pas la même chose qu’un ensemble sain simplement démonté, et les commandes de montage ne peuvent pas réparer l’étape d’activation manquante.

Un état d’ensemble inactif est configuré mais non actif, avec des E/S retournant des erreurs. Cet état permet au système de continuer à découvrir ou reconfigurer les membres sans prétendre que l’ensemble est prêt.

Inspectez /proc/mdstat, les détails de l’ensemble et chaque superbloc de membre avant de changer d’état. L’objectif est de comprendre pourquoi l’activation s’est arrêtée, pas de transformer « inactif » en « actif » sans confirmer l’ensemble des membres.

Un ou plusieurs membres peuvent ne pas être réapparus

Une panne soudaine peut révéler un câble d’alimentation, un backplane, un câble SATA, un port contrôleur ou un disque défaillant qui ne s’initialise pas au démarrage suivant. L’ensemble voit alors moins de membres que ce que ses métadonnées indiquent.

mdadm compare normalement les périphériques non de secours disponibles avec le nombre actif attendu avant de démarrer. Un ensemble peut rester partiellement assemblé lorsque des périphériques attendus sont manquants, même si suffisamment de métadonnées existent pour créer une entrée de périphérique md.

Éteignez en toute sécurité si une inspection matérielle est nécessaire, puis vérifiez les connecteurs, la mise en rotation, la détection du contrôleur, les numéros de série et les données SMART. Restaurez la connectivité manquante avant de choisir un démarrage dégradé, car une défaillance transitoire du chemin peut être plus facile et plus sûre à réparer que de reconstruire l’ensemble.

Un arrêt non propre peut laisser l’ensemble sale

Une coupure de courant peut interrompre les écritures avant que chaque membre et bloc de parité n’atteigne un état cohérent. Les métadonnées de l’ensemble enregistrent alors qu’une resynchronisation, une relecture de bitmap, une relecture de journal ou une autre action de cohérence est requise au prochain démarrage.

Linux md prend en charge différentes politiques de cohérence après un arrêt inattendu, y compris la resynchronisation complète, le bitmap d’intention d’écriture, le journal et le journal partiel de parité. La politique de cohérence détermine la quantité de travail nécessaire avant que la redondance puisse de nouveau être fiable.

Un ensemble sale mais complet peut démarrer et se resynchroniser normalement. Un ensemble sale et dégradé nécessite beaucoup plus de prudence, car les données manquantes et la parité incertaine peuvent supprimer les informations nécessaires à une reconstruction fiable.

Une parité sale et dégradée peut déclencher un refus de sécurité

Le RAID 5 ou RAID 6 peut être refusé au démarrage lorsqu’il est à la fois sale et qu’un membre est manquant. Ce refus protège contre un état où la parité peut être obsolète et les données absentes ne peuvent pas être vérifiées par rapport à une autre copie.

Une protection au démarrage sale-dégradé existe car forcer cette combinaison peut créer une corruption indétectable. Par conséquent, le démarrage dégradé forcé est une décision explicite de l’administrateur plutôt qu’un comportement normal de démarrage.

Ne contournez pas cette protection tant que le membre manquant, le statut de sauvegarde et l’historique d’écriture ne sont pas compris. Restaurez d’abord le chemin du périphérique ou clonez les membres défaillants ; si la récupération doit continuer, minimisez les écritures et vérifiez les fichiers récupérés de manière indépendante.

La découverte et la configuration au démarrage peuvent être incomplètes

Les disques peuvent tous être sains alors que le démarrage ne détecte pas l’ensemble parce que la découverte des périphériques se termine après la tentative d’assemblage, que la configuration manque l’identité de l’ensemble, ou que l’initramfs contient des paramètres RAID obsolètes.

Un fichier de configuration RAID peut décrire les périphériques et ensembles afin que les outils de démarrage sachent quoi scanner et assembler. Des enregistrements de configuration d’ensemble précis sont particulièrement importants lorsque la découverte automatique ne peut pas déduire de manière fiable l’ensemble prévu.

Comparez les UUID des membres en direct avec la configuration installée et l’environnement de démarrage. Corrigez la configuration obsolète uniquement après avoir confirmé l’identité réelle de l’ensemble ; générer une nouvelle configuration à partir d’un ensemble de membres incomplet peut rendre le prochain démarrage systématiquement erroné.

Les métadonnées externes peuvent nécessiter leur gestionnaire en espace utilisateur

Certains ensembles utilisent des formats de métadonnées externes gérés par l’espace utilisateur plutôt que entièrement par le noyau. Après une panne brutale, le processus conteneur ou de surveillance peut ne pas avoir terminé les accusés de réception nécessaires aux changements d’état des membres.

Les métadonnées gérées en externe peuvent suspendre l’activité jusqu’à ce que l’espace utilisateur accuse réception d’un événement. Un ensemble de composants inactifs peut donc refléter une étape de gestion manquante plutôt que des disques de données défaillants.

Identifiez le format des métadonnées avant d’appliquer des commandes md génériques. Les formats assistés par firmware ou conteneur peuvent nécessiter le moniteur approprié, l’utilitaire de contrôleur ou le flux de récupération NAS afin que les mises à jour des métadonnées se produisent dans le bon ordre.

Récupérez dans l’ordre de risque le plus faible

Commencez par des preuves en lecture seule : listez les périphériques bloc par ID stable, associez les numéros de série aux emplacements, examinez les métadonnées des membres, consultez les journaux du démarrage précédent et vérifiez que chaque disque attendu est présent. Ne créez pas un nouvel ensemble ni ne zéros les superblocs.

Tentez l’assemblage normal de la plateforme après correction de la connectivité et de la configuration. Utilisez les modes lecture seule ou lecture automatique quand ils sont pris en charge, et réservez les options de fonctionnement dégradé ou forcé aux cas où le membre manquant exact et le risque de cohérence sont compris.

Après la récupération, terminez toute resynchronisation ou nettoyage, confirmez les sauvegardes et enquêtez sur la cause de la panne. Un onduleur, une alimentation et un câblage fiables, une configuration RAID à jour, des ID de périphériques stables et une alerte réduisent la probabilité que le prochain événement de coupure présente le même état inactif.