Warum wird ein RAID-Array nach einem Stromausfall inaktiv?

Nach einem Stromausfall kann ein RAID-Array inaktiv bleiben, weil seine Metadaten erkannt wurden, das System es jedoch nicht sicher mit den verfügbaren Mitgliedern und dem aktuellen Zustand starten konnte.

Der Begriff „inaktiv“ beschreibt am direktesten Linux-md-Arrays, obwohl andere Speicher-Stacks ähnliche Import- oder Aktivierungsfehler aufweisen. Überprüfen Sie die Geräteerkennung, Mitgliedsmetadaten, schmutzigen oder degradierten Zustand, Startkonfiguration und Fehler im Strompfad, bevor Sie einen erzwungenen Start versuchen.

Verstehen, was „inaktiv“ im Linux-RAID bedeutet

Ein inaktives md-Array kann Geräte und eine gewisse Konfiguration enthalten, verweigert jedoch den normalen I/O. Es ist nicht dasselbe wie ein gesundes Array, das lediglich nicht eingehängt ist, und Mount-Befehle können den fehlenden Aktivierungsschritt nicht reparieren.

Ein inaktiver Array-Zustand ist konfiguriert, aber nicht aktiv, wobei I/O-Operationen Fehler zurückgeben. Dieser Zustand ermöglicht es dem System, weiterhin Mitglieder zu entdecken oder neu zu konfigurieren, ohne vorzutäuschen, dass das Array einsatzbereit ist.

Untersuchen Sie /proc/mdstat, die Array-Details und jeden Mitglied-Superblock, bevor Sie den Zustand ändern. Das Ziel ist es, zu verstehen, warum die Aktivierung gestoppt wurde, und nicht, „inaktiv“ einfach in „aktiv“ zu verwandeln, ohne die Mitgliedermenge zu bestätigen.

Ein oder mehrere Mitglieder sind möglicherweise nicht wieder aufgetaucht

Ein plötzlicher Ausfall kann eine mangelhafte Stromverbindung, Backplane, SATA-Kabel, Controller-Port oder Festplatte offenbaren, die beim nächsten Start nicht initialisiert wird. Das Array sieht dann weniger Mitglieder, als seine Metadaten vorgeben.

mdadm vergleicht normalerweise die verfügbaren Nicht-Ersatzgeräte mit der erwarteten aktiven Anzahl vor dem Start. Ein Array kann teilweise zusammengebaut bleiben, wenn erwartete Geräte fehlen, obwohl genügend Metadaten vorhanden sind, um einen md-Geräteeintrag zu erstellen.

Fahren Sie das System sicher herunter, wenn eine Hardwareinspektion erforderlich ist, und überprüfen Sie dann Anschlüsse, Hochlauf, Controller-Erkennung, Seriennummern und SMART-Daten. Stellen Sie fehlende Verbindungen wieder her, bevor Sie einen degradierten Start wählen, da ein vorübergehender Pfadfehler leichter und sicherer zu beheben sein kann als die Rekonstruktion des Arrays.

Ein unsauberes Herunterfahren kann das Array „schmutzig“ hinterlassen

Ein Stromausfall kann Schreibvorgänge unterbrechen, bevor jedes Mitglied und jeder Paritätsblock einen konsistenten Zustand erreicht hat. Die Array-Metadaten vermerken dann, dass beim nächsten Start eine Resynchronisation, Bitmap-Wiedergabe, Journal-Wiedergabe oder eine andere Konsistenzmaßnahme erforderlich ist.

Linux md unterstützt nach einem unerwarteten Herunterfahren verschiedene Konsistenzrichtlinien, darunter vollständige Resynchronisation, Write-Intent-Bitmap, Journal und partielles Paritätsprotokoll. Die Konsistenzrichtlinie bestimmt, wie viel Arbeit nötig ist, bevor der Redundanz wieder vertraut werden kann.

Ein schmutziges, aber vollständiges Array kann normal starten und resynchronisieren. Ein schmutziges Array, das zudem degradiert ist, erfordert deutlich mehr Vorsicht, da fehlende Daten und unsichere Parität die Informationen für eine zuverlässige Rekonstruktion entfernen können.

Schmutzige und degradierte Parität kann eine Sicherheitsverweigerung auslösen

RAID 5 oder RAID 6 kann beim Start verweigert werden, wenn es sowohl schmutzig als auch ein Mitglied fehlt. Die Verweigerung schützt vor einem Zustand, in dem die Parität veraltet sein könnte und die fehlenden Daten nicht mit einer anderen Kopie überprüft werden können.

Ein Schutzmechanismus für schmutzig-degradierten Start existiert, weil das Erzwingen dieser Kombination unentdeckbare Korruption verursachen kann. Daher ist der erzwungene degradierte Start eine explizite Administratorentscheidung und kein normales Boot-Verhalten.

Umgehen Sie diesen Schutz nicht, bevor das fehlende Mitglied, der Backup-Status und die Schreibhistorie verstanden sind. Stellen Sie zuerst den Gerätepfad wieder her oder klonen Sie fehlerhafte Mitglieder; wenn die Wiederherstellung fortgesetzt werden muss, minimieren Sie Schreibvorgänge und überprüfen Sie wiederhergestellte Dateien unabhängig.

Die Erkennung und Konfiguration beim Booten kann unvollständig sein

Die Festplatten können alle gesund sein, während der Start das Array dennoch nicht findet, weil die Geräteerkennung erst nach dem Zusammenbauversuch abgeschlossen wird, die Konfiguration die Array-Identität nicht enthält oder das initramfs veraltete RAID-Einstellungen hat.

Eine RAID-Konfigurationsdatei kann Geräte und Arrays beschreiben, damit Startwerkzeuge wissen, was gescannt und zusammengebaut werden soll. Genaue Array-Konfigurationsaufzeichnungen sind besonders wichtig, wenn die automatische Erkennung die beabsichtigte Menge nicht zuverlässig ableiten kann.

Vergleichen Sie die aktiven Mitglied-UUIDs mit der installierten Konfiguration und der Boot-Umgebung. Korrigieren Sie veraltete Konfigurationen erst, nachdem die tatsächliche Array-Identität bestätigt wurde; das Erzeugen einer neuen Konfiguration aus einer unvollständigen Mitgliedermenge kann den nächsten Start dauerhaft fehlerhaft machen.

Externe Metadaten benötigen möglicherweise ihren Userspace-Manager

Einige Arrays verwenden externe Metadatenformate, die vom Userspace und nicht vollständig vom Kernel verwaltet werden. Nach einem abrupten Ausfall hat der Container- oder Überwachungsprozess möglicherweise die für Mitgliedszustandsänderungen erforderlichen Bestätigungen nicht abgeschlossen.

Extern verwaltete Metadaten können die Aktivität aussetzen, bis der Userspace ein Ereignis bestätigt. Ein inaktives Komponenten-Set kann daher einen fehlenden Verwaltungsschritt widerspiegeln und nicht ausgefallene Datenträger.

Identifizieren Sie das Metadatenformat, bevor Sie generische md-Befehle anwenden. Firmware-unterstützte oder Containerformate erfordern möglicherweise das passende Überwachungs-, Controller-Tool oder NAS-Wiederherstellungsverfahren, damit Metadatenaktualisierungen in der richtigen Reihenfolge erfolgen.

Wiederherstellung in der risikoärmsten Reihenfolge

Beginnen Sie mit schreibgeschützten Beweisen: Listen Sie Blockgeräte nach stabiler ID auf, ordnen Sie Seriennummern den Slots zu, prüfen Sie Mitgliedsmetadaten, sehen Sie sich die Protokolle des vorherigen Starts an und kontrollieren Sie, ob jede erwartete Festplatte vorhanden ist. Erstellen Sie kein neues Array und löschen Sie keine Superblöcke.

Versuchen Sie den normalen Zusammenbau der Plattform, nachdem Konnektivität und Konfiguration korrigiert wurden. Verwenden Sie schreibgeschützte oder automatische Lesemodi, wenn unterstützt, und reservieren Sie degradierte Lauf- oder Zwangsoptionen für Fälle, in denen das exakt fehlende Mitglied und das Konsistenzrisiko verstanden sind.

Nach der Wiederherstellung führen Sie alle Resync- oder Scrub-Vorgänge durch, bestätigen Sie Backups und untersuchen Sie den Ausfallpfad. Eine USV, zuverlässige Stromversorgung und Verkabelung, aktuelle RAID-Konfiguration, stabile Geräte-IDs und Alarmierung verringern die Wahrscheinlichkeit, dass das nächste Stromereignis denselben inaktiven Zustand verursacht.