RAID-1-Wiederherstellung: ein Spiegel reicht meistens, und zwei Befehle zerstören beide

RAID 1 ist die Stufe, auf der die Rettung einfach sein sollte. Es gibt keine Parität, die neu berechnet werden müsste, keine Stripe-Reihenfolge, die zu ermitteln wäre, und jede Platte trägt eine vollständige Kopie von allem. In der Praxis ist es auch die Stufe, auf der Leute ihre eigenen Daten am beiläufigsten zerstören, weil der Verbund noch lebendig aussieht und die Lösung offensichtlich wirkt.

Selten ist es der Ausfall, der die Daten kostet. Es ist der nächste Befehl.

Was Spiegelung dir gibt, und die eine Sache, die sie nie geleistet hat

RAID 1 hält zwei oder mehr Platten identisch. Jeder Schreibvorgang geht an jedes Mitglied, jedes einzelne Mitglied ist also eine vollständige Kopie des Ganzen. Das ist der gesamte Mechanismus, und deshalb stehen die Chancen auf Rettung gut.

Es ist auch der Grund, warum der Schutz enger ist, als man annimmt. Ein Löschvorgang ist ein Schreibvorgang. Genauso eine Verschlüsselung durch Ransomware, eine überschriebene Datei, ein beschädigtes Speichern. Die Spiegelung überträgt all das mit Maschinengeschwindigkeit getreu auf beide Platten, denn genau das ist ihre Aufgabe.

RAID 1 schützt davor, dass eine Platte stirbt. Es hat nie vor etwas geschützt, das die Daten über das Dateisystem erreicht. Wenn deine Dateien verschwunden sind und die Laufwerke gesund sind, hat der Verbund genau das getan, wofür er gebaut wurde, und kein RAID-Wissen bringt sie zurück. Das ist ein Dateirettungsproblem auf einem Spiegel, kein RAID-Problem.

Die Regel, die über den Ausgang entscheidet

Vor jeder Diagnose gibt das Linux RAID wiki eine einzige Anweisung, und die Klammer ist der wichtige Teil:

Führe keine Befehle aus, die auf die Platten schreiben (wie mdadm -C, fsck oder sogar mount usw.).

Die meisten lesen diese Liste und hören nach den ersten beiden auf. mount steht darauf. Ein journalendes Dateisystem spielt beim Mounten sein Journal nach, und das ist ein Schreibvorgang, ausgeführt, bevor du irgendetwas entschieden hast. Auf einem degradierten Verbund mit einem Mitglied, das du noch nicht als gut identifiziert hast, kann dieser Schreibvorgang an der denkbar schlechtesten Stelle landen.

Dieselbe Seite schließt den Ansatz aus, den unter Druck fast jeder wählt:

Versuche nicht, die Dinge nach Versuch und Irrtum zu reparieren, lass jemanden die Maßnahmen prüfen, die du zur Rettung deiner Daten ergreifen willst, bevor du sie in die Praxis umsetzt.

Versuch und Irrtum funktioniert, wenn Versuche kostenlos sind. Hier kann jeder Versuch derjenige sein, der die Kopie entfernt, die du gebraucht hättest.

Drei Situationen, und nur eine davon ist schwierig

Ein Mitglied ist ausgefallen und der Verbund läuft noch. Das ist der gute Fall und er verdient kein Drama. Du hast eine vollständige Kopie. Kopiere deine Daten jetzt woandershin, bevor du dich um die defekte Platte kümmerst. Sie zuerst zu ersetzen und neu aufzubauen setzt deine einzige überlebende Kopie einem Lesevorgang über die gesamte Platte aus, genau in dem Moment, in dem du dir einen zweiten Ausfall nicht leisten kannst.

Der Controller oder die Maschine ist gestorben und die Platten sind in Ordnung. Es ist nichts verloren. Die Daten sind auf jedem Mitglied intakt, und die einzige Frage ist, wie du an sie herankommst, was die Metadatenversion weiter unten beantwortet.

Die Mitglieder weichen voneinander ab und du weißt nicht, welches aktuell ist. Das ist der einzige wirklich schwierige Fall, und er ist ein Diagnose-, kein Reparaturproblem. Alles, was Daten zerstört, wohnt hier.

Zwei identisch aussehende Objektive, und nur eines bringt etwas auf den Film. Zu wissen, welches welches ist, ist die ganze Arbeit.

Warum deine einzelne Platte unformatiert wirkt

Der Rat, den du überall findest, lautet, dass du eine Platte aus einem Spiegel ziehen und wie ein normales Laufwerk lesen kannst. Das stimmte, und der Standardwert hat sich geändert.

Das mdadm-Handbuch ist präzise:

Die verschiedenen Unterversionen legen den Superblock an unterschiedlichen Stellen des Geräts ab, entweder am Ende (bei 1.0), am Anfang (bei 1.1) oder 4K nach dem Anfang (bei 1.2).

Lies, was das bedeutet. Bei 1.0 sitzt der Superblock am Ende, das Dateisystem beginnt bei Offset null, und ein einzelnes Mitglied verhält sich tatsächlich wie eine gewöhnliche Platte. Bei 1.1 und 1.2 belegen die Metadaten den Anfang, das Dateisystem beginnt also weiter hinten. Ein Werkzeug, das auf Offset null schaut, findet Metadaten dort, wo es eine Partitionstabelle erwartet hat, und meldet die Platte als unformatiert oder roh.

1.2 ist der moderne Standard. Das häufigste Ergebnis bei der häufigsten Konfiguration ist also eine Platte, die leer aussieht und vollständig intakt ist. Wer in diesem Moment einer Formatierungsaufforderung nachgibt, verliert alles, und die Platte war nie beschädigt. Sie war verschoben.

Der Befehl, der Verbünde frisst

Wenn das Assemblieren fehlschlägt, wird das Internet vorschlagen, den Verbund mit denselben Parametern neu zu erstellen. Das wiki geht direkt darauf ein:

Neuerstellen sollte als letzter Ausweg gelten, der nur zu nutzen ist, wenn alles andere scheitert. Leute, die das falsch machen, sind einer der Hauptgründe für Datenverlust.

Und es erklärt die Falle, die es so unnachsichtig macht:

Ein mdadm mit anderen Standardwerten zu verwenden als jenes, mit dem der Verbund ursprünglich erstellt wurde, führt dazu, dass der Verbund vollständig unzugänglich wird.

Die Parameter, auf die es ankommt, sind nicht nur die, die du eintippst. Dazu gehören die Standardwerte der mdadm-Version, die den Verbund vor Jahren gebaut hat, auf einer Distribution, die du vielleicht gar nicht mehr betreibst. Ein Neuerstellen mit den heutigen Standardwerten schreibt das heutige Metadatenlayout über das gestrige, und diese Nichtübereinstimmung lässt sich nicht durch einen weiteren Versuch beheben.

--assemble verwendet weiter, was bereits auf den Platten liegt. Das Handbuch beschreibt es als das Zusammenfügen der Komponenten eines zuvor erstellten Verbunds zu einem aktiven Verbund. Das ist die sichere Richtung: Es liest die vorhandene Beschreibung, statt sie zu ersetzen. Und wenn du assemblierst, existiert --readonly genau für diesen Moment. Das Handbuch hält fest, dass es den Verbund schreibgeschützt statt wie üblich lesend-schreibend startet, wobei keine Schreibzugriffe auf den Verbund erlaubt sind und keine Resynchronisierung, Wiederherstellung oder Reshape angestoßen wird. Ein Rebuild, der von selbst beginnt, bevor du das aktuelle Mitglied identifiziert hast, ist genau der Fehlerfall, gegen den du dich absicherst.

Die Reihenfolge, die dir alle Optionen offenhält

Schalte ab, statt zu experimentieren. Ein degradierter Verbund, den man laufen lässt, ist ein Rebuild, der nur auf seinen Start wartet.

Erstelle vor allem anderen ein Image beider Mitglieder. Nicht vom guten, von beiden. Eine Platte zu klonen ist ein Lesevorgang, kostet dich also nichts, und jeder spätere Fehler wird umkehrbar. Dieser eine Schritt trennt einen schlechten Nachmittag von einem endgültigen Verlust.

Arbeite an den Kopien. Schreibgeschützt assemblieren, schreibgeschützt mounten, aus Images retten.

Identifiziere das aktuelle Mitglied vor dem Rebuild, nicht danach. Waren beide Platten bis vor Kurzem online, vergleiche, was die Metadaten über jede sagen. Wenn du es nicht sagen kannst, ist das ein Grund aufzuhören, kein Grund, eine auszuwählen.

Baue zuletzt neu auf. Sobald deine Daten vollständig woanders liegen, kostet eine falsche Vermutung nichts.

Die Kurzfassung

RAID 1 ist die am besten rettbare Stufe überhaupt, denn jede Platte ist eine vollständige Kopie und es gibt nichts zu rekonstruieren. Was das ruiniert, ist Schreiben vor dem Diagnostizieren, und das Linux RAID wiki setzt mount auf die Liste der Dinge, die schreiben.

Wenn deine Platte unformatiert wirkt, nachdem du sie aus dem Verbund gezogen hast, prüfe die Metadatenversion, bevor du das glaubst. Bei 1.1 und 1.2, den modernen Standardwerten, beginnt das Dateisystem nicht bei Offset null und die Platte ist intakt. Und behandle das Neuerstellen des Verbunds als das Allerletzte, was du je versuchst, denn die Standardwerte, die ihn gebaut haben, zählen genauso viel wie die Parameter, an die du dich erinnerst.

Erstelle Images beider Platten, assembliere schreibgeschützt, und baue erst neu auf, wenn die Daten irgendwo sicher liegen, das nicht der Verbund ist.

Die Anweisung, keine Befehle auszuführen, die auf die Platten schreiben, mount eingeschlossen, die Warnung vor Reparatur nach Versuch und Irrtum, die Beschreibung des Neuerstellens als letzter Ausweg und der Hinweis auf abweichende mdadm-Standardwerte stammen aus dem Linux RAID wiki. Die Speicherorte des Metadaten-Superblocks für die Versionen 1.0, 1.1 und 1.2, die Beschreibung von --assemble und das Verhalten von --readonly stammen aus der mdadm-Handbuchseite. Beides wurde zum Zeitpunkt des Schreibens geprüft; gleiche es mit der mdadm-Version ab, die du einsetzt. Kommerzielle Links tragen das Attribut rel="sponsored nofollow"; eine Affiliate-Provision kann anfallen, ohne dass für dich zusätzliche Kosten entstehen.

Verwandte Leitfäden

• RAID-Datenrettung: die vollständige Methode für RAID 0, 1, 5, 6 und 10 - das Gesamtbild, einschließlich der Paritätsstufen, auf die die Spiegel-Logik nicht mehr passt.
• RAID-Recovery-Software im Vergleich - was die Werkzeuge rekonstruieren können und was nicht, sobald die Klone vorliegen.