Die wichtigste Korrektur in dieser Quelle ist, dass das Array nicht dauerhaft als bestätigtes RAID mit „einer ausgefallenen Festplatte“ bestehen blieb. Nachdem der Benutzer mit jeweils nur einem Laufwerk gestartet hatte, waren beide einzeln funktionsfähig. Das erneute Anschließen beider Laufwerke erzeugte [UU] in /proc/mdstat, was bedeutet, dass beide RAID-1-Mitglieder zu diesem Zeitpunkt vorhanden und synchronisiert waren.
Der Thread weitete sich anschließend auf SATA-/Link-/Stromversorgungsinstabilität, USB-/Monitorfehler, Starts im Notfallmodus, NFS-Fehler und den Rückfall von ZimaOS auf den anderen System-Slot aus. Die Daten wurden wiederhergestellt, aber die Quelle belegt keine einzige endgültige Ursache. Machen Sie daraus keine einfache Anleitung nach dem Muster „Festplatte X ersetzen“.
Klicken Sie nicht auf „Aufbrechen“ oder „Formatieren“, solange eine Wiederherstellung noch möglich ist
Der erste Ratschlag der Community war in diesem Sicherheitspunkt richtig: Wenn die Daten wichtig sind und der tatsächliche Zustand des Arrays unbekannt ist, können destruktive Aktionen in der Benutzeroberfläche die Wiederherstellung erschweren. Sichern Sie zuerst die lesbaren Daten.
Jede Festplatte funktionierte im Einzeltest
Der ursprüngliche Verfasser trennte die Laufwerke nacheinander und erklärte, dass jedes Laufwerk einzeln einen funktionsfähigen System-/Datenpfad ergab. Dadurch wurde die Annahme, dass eine Festplatte physisch ausgefallen war, unmittelbar geschwächt.
Das erneute Anschließen beider Laufwerke erzeugte ein intaktes [UU]-md-Array
Das angezeigte Statusbild zeigte md0 : aktives RAID1 ... [2/2] [UU]. Zu diesem Zeitpunkt betrachtete die Linux-md-Ebene beide Mitglieder als vorhanden.
Deshalb verlagerte sich die spätere Diskussion auf Kabel, SATA-Anschluss, Controller, Adapter/Backplane und Stromversorgungsstabilität statt ausschließlich auf RAID-Metadaten.
SATA-/Strominstabilität kann sich als RAID-Fehler tarnen
Später wurden in der Quelle umfassendere Fehler gemeldet, die SATA-, USB- und Anzeigeverhalten betrafen. Zu den Vorschlägen der Community gehörten der Austausch der SATA-Kabel, das Testen anderer Anschlüsse, das Vermeiden grenzwertiger Splitter/Adapter sowie ein Belastungstest unter Beobachtung möglicher I/O-Resets.
Das waren Diagnosen der Community, kein von IceWhale bestätigter Hardwaredefekt.
Spätere Probleme mit dem Notfallmodus und NFS waren eine separate Ebene
Nach Kabeländerungen und Neustarts wechselte das System in den Notfallmodus und zeigte NFS-/RPC-bezogene Fehler. Die Versuche der Community, den NFS-Status zu löschen oder NFS zu deaktivieren, führten zu keiner bestätigten Reparatur.
Schließen Sie nicht daraus, dass NFS die ursprüngliche Nichterreichbarkeit des RAID verursacht hat; NFS trat später auf einem System auf, das bereits eine umfassendere Instabilität zeigte.
Das System ist ebenfalls auf den anderen ZimaOS-Slot zurückgefallen
Der Benutzer berichtete, dass das System von Block/Slot B statt A gestartet wurde. Das aktuelle ZimaOS verwendet zwei System-Slots zur Wiederherstellung. Daher kann der Fallback darauf hindeuten, dass einer der System-Slots die Integritäts- oder Startprüfungen nicht bestanden hat, und nicht, dass die Benutzerdaten auf dem RAID verloren sind.
Siehe das aktuelle Dual-Slot-Wiederherstellungsmodell von ZimaOS.
Das aktuelle ZimaOS verfügt über einen offiziellen Workflow zur Reparatur von RAID 1
ZimaOS 1.4.4 führte die RAID-1-Reparatur für beeinträchtigte oder beschädigte Arrays ein und behob das Problem, dass zuvor verwendete Laufwerke während der Wiederherstellung nicht verfügbar waren.
Verwenden Sie die offizielle RAID-1-Reparaturfunktion, bevor Sie alte manuelle mdadm-Befehle zur Änderung des Arrays anwenden.
RAID-Metadaten sind in neueren ZimaOS-Versionen robuster
ZimaOS 1.6.0 führte einen Mechanismus zum Speichern von RAID-Metadaten ein, der dafür ausgelegt ist, das ursprüngliche Array nach einer Neuinstallation des Betriebssystems oder einem Geräteaustausch automatisch wiederzuerkennen und einzubinden. Das verbessert den Wiederherstellungsweg gegenüber der Ära der Quelle mit ZimaOS 1.5.x.
Sicherere aktuelle Reihenfolge der Wiederherstellung
- Formatieren Sie das Array nicht und lösen Sie es nicht auf.
- Ermitteln Sie Laufwerksmodelle und Seriennummern sowie den aktuellen RAID-Zustand mithilfe schreibgeschützter Diagnosen.
- Sichern Sie sofort alle zugänglichen Daten.
- Überprüfen Sie Kabel, Anschlüsse, Stromversorgung, SMART sowie Kernel-Protokolle zu I/O-Fehlern und Zurücksetzungen.
- Verwenden Sie die aktuelle RAID-Reparaturoberfläche, wenn das Array tatsächlich beeinträchtigt ist.
- Behandeln Sie die Wiederherstellung des Betriebssystem-Slots getrennt von der Wiederherstellung der RAID-Daten.
Der Wiederherstellungsverlauf führte schließlich zu den Optionen zum Zurücksetzen und Wiederherstellen von ZimaOS
Ein [UU]-md-Status bedeutet, dass zu diesem Zeitpunkt beide RAID-1-Mitglieder vorhanden waren
Nach dem erneuten Anschließen beider Laufwerke zeigte die Quelle das Array mit zwei aktiven Mitgliedern an, und [UU]. Das war ein deutlicher Hinweis darauf, dass der Spiegel zu diesem Zeitpunkt erfolgreich wieder zusammengesetzt worden war.
Es erklärt nicht, warum das Array zuvor als nicht zugänglich erschienen war oder warum die späteren SATA-/USB-/Monitor-Instabilitäten anhielten.
Schreibgeschützte Diagnosen sind sicherer als manuelle mdadm-Reparaturbefehle
Die Community bat um Informationen zum Array und dessen Status, bevor Änderungen vorgeschlagen wurden. Das ist die richtige Reihenfolge: Ermitteln Sie, welche Geräte zum Array gehören, ob es aktiv oder degradiert ist und was der Kernel meldet, bevor Sie Mitglieder hinzufügen oder entfernen oder die Metadaten neu erstellen.
Kopieren Sie keinen mdadm --create, dem erzwungenen Zusammenfügen oder dem Löschen des Superblocks aus einem anderen Linux-Fall in ein RAID kopieren, das die einzige Kopie Ihrer Daten enthält.
Wichtige Daten kopieren, sobald das Array lesbar wird
Der Benutzer aus der Quelle erlangte wieder Zugriff. Zu diesem Zeitpunkt sollte die Priorität darin liegen, unersetzliche Daten auf unabhängigen Speicher zu kopieren, bevor weitere Experimente mit Kabeln, Controllern, System-Slots, NFS oder einer Neuinstallation durchgeführt werden.
RAID 1 bietet Redundanz, aber ein instabiler Host oder Controller kann dazu führen, dass beide Mitglieder gleichzeitig nicht verfügbar sind.
Wenn SATA-, USB- und Anzeigeprobleme gemeinsam auftreten, sollte die Diagnose ausgeweitet werden
Die späteren Symptome ließen sich nicht mehr eindeutig als Ausfall eines einzelnen Laufwerks erklären. Eine intermittierende SATA-Erkennung, USB-Probleme sowie Monitor-/Startprobleme können auf Verkabelung, Stromversorgung, Controller, Motherboard-Firmware oder eine andere Instabilität der Plattform hindeuten.
Testen Sie bekannte funktionierende Netzteile und Kabel und vereinfachen Sie die Hardwarekonfiguration, bevor Sie das RAID wiederholt neu aufbauen.
Die Wiederherstellung des System-Slots und die RAID-Wiederherstellung sind getrennt
ZimaOS kann für die Betriebssystemwiederherstellung von alternativen System-Slots starten. Der Wechsel auf Slot B kann ein Problem mit dem Betriebssystem-Slot beheben oder umgehen, repariert jedoch nicht selbst ein degradiertes Array.
Verwenden Sie das aktuelle Systemwiederherstellungsmodell von ZimaOS, wenn auch der Betriebssystem-Slot fehlerhaft ist.
Datenlaufwerke bei der Neuinstallation des Betriebssystems trennen, sofern der Wiederherstellungsplan dies vorsieht
Die Quell-Community empfahl, die RAID-Laufwerke während einer sauberen Neuinstallation des Betriebssystems zu isolieren, um das Risiko zu verringern, das falsche Laufwerk auszuwählen oder zu verändern. Wenn der aktuelle IceWhale-Support einen Neuinstallationsplan bereitstellt, beschriften Sie jedes Laufwerk und sichern Sie zuerst die Speicher-Metadaten und Backups.
FAQ zur Wiederherstellung von RAID 1
War in der Quelle eindeutig festgestellt worden, dass ein Laufwerk defekt war?
Nein. Beide Laufwerke funktionierten später unabhängig voneinander, und das Array zeigte [UU] als es wieder angeschlossen wurde.
Hat die Quelle eine endgültige Ursache festgestellt?
Nein. RAID-, SATA-/Strominstabilitäts-, NFS-Start- und Betriebssystem-Slot-Probleme überschnitten sich.
Unterstützt das aktuelle ZimaOS die Reparatur von RAID 1?
Ja. IceWhale hat in 1.4.4 einen offiziellen Reparaturablauf für RAID 1 hinzugefügt.
