ZimaOS RAID 1 nach einer Neuinstallation des Betriebssystems wiederherstellen

Wenn ZimaOS neu installiert wird und ein vorhandenes RAID 1 als ungenutzte Datenträger erscheint, klicken Sie nicht sofort auf RAID erstellen. Das erneute Erstellen oder Formatieren des Arrays kann die auf den Mitgliedsdatenträgern noch vorhandenen Daten zerstören.

Der erste Wiederherstellungsweg sollte die aktuelle offizielle ZimaOS-Methode sein: die gespeicherte local-storage.db Datei aus der vorherigen Systeminstallation. Das Community-Tutorial hinter dieser Seite beschreibt eine invasivere Ausweichlösung für den schwierigeren Fall, dass diese Datenbank nicht gesichert wurde. Diese Ausweichlösung wurde mit ZimaOS 1.6.1 getestet, umfasst jedoch destruktive RAID-Operationen und sollte erst in Betracht gezogen werden, nachdem die Quelldaten unabhängig kopiert und überprüft wurden.

Erste Wahl: local-storage.db wiederherstellen

ZimaOS speichert Informationen zur Speicherkonfiguration unter:

/ZimaOS-HD/.casaos/db/local-storage.db

Die aktuelle offizielle Wiederherstellungsanleitung empfiehlt, diese Datei vor der Neuinstallation herunterzuladen, sie anschließend nach der neuen ZimaOS-Installation wieder in dasselbe Verzeichnis zu kopieren und danach neu zu starten.

Offizielle RAID-Wiederherstellung in ZimaOS nach einer Neuinstallation

Wenn Sie noch Zugriff auf den alten Systemdatenträger haben, versuchen Sie, diese Datenbank wiederherzustellen, bevor Sie die RAID-Mitgliedsdatenträger verändern.

Warum das Daten-Array möglicherweise noch intakt ist

ZimaOS verwendet Linux-Software-RAID. Die Mitgliedsdatenträger können RAID-Metadaten behalten, selbst wenn die neue ZimaOS-Installation die alte Speicherdatenbank nicht mehr besitzt. Deshalb können die Datenträger physisch vorhanden sein, während die Benutzeroberfläche den ursprünglichen Pool nicht mehr erkennt.

ZimaOS 1.6 führte außerdem eine verbesserte Wiederherstellung und erneute Erkennung von RAID-Metadaten ein. Daher sollte nicht angenommen werden, dass ein ursprünglich auf einem System beobachtetes Problem in jeder neueren Version identisch auftritt.

Erstellen Sie kein neues RAID, bevor die Wiederherstellungsstrategie feststeht

Wenn die Datenträger benötigte Daten enthalten, vermeiden Sie Folgendes:

einen der Mitgliedsdatenträger zu formatieren;
ein neues RAID über denselben Datenträgern zu erstellen;
auszuführen wipefs oder mdadm --zero-superblock vorzeitig;
raten, welches /dev/sdX Welches Gerät ist welches?

Identifizieren Sie die Datenträger vor jeder Wiederherstellungsmaßnahme anhand von Modell, Seriennummer und Kapazität, statt sich ausschließlich auf Gerätebuchstaben zu verlassen.

RAID-Metadaten schreibgeschützt überprüfen

Der Community-Autor nutzte zunächst eine schreibgeschützte Prüfung, um zu bestätigen, dass beide RAID-1-Mitglieder weiterhin zum selben Array gehörten.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL

mdadm --examine /dev/sda
mdadm --examine /dev/sdb

Für ein intaktes RAID 1 sollten beide Mitglieder dieselbe Array-UUID und kompatible RAID-Metadaten melden. Wenn ein Mitglied fehlt, degradiert ist oder andere Metadaten meldet, halten Sie an und holen Sie Unterstützung bei der Wiederherstellung ein, statt einem allgemeinen Wiederherstellungsrezept zu folgen.

Altes Array schreibgeschützt zusammenbauen und einhängen

Für eine erweiterte Wiederherstellung verringert das schreibgeschützte Zusammenbauen das Risiko, die Quelle zu verändern, während Sie überprüfen, ob auf die Dateien zugegriffen werden kann:

mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb

mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraid

Untersuchen Sie anschließend das Dateisystem:

df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*

Die oben genannten Gerätenamen dienen nur als Beispiele. Fügen Sie sie niemals unverändert ein, bevor Sie bestätigt haben, dass sie zu Ihrer Hardware passen.

Vollständige Auslagerungskopie vor jedem destruktiven Schritt erstellen

Das Ausgangsverfahren verwendete ein externes ext4-Laufwerk, das groß genug war, um alle verwendeten RAID-Daten aufzunehmen. Für Linux-Anwendungsdaten ist ext4 hilfreich, da es reguläre Eigentümer, Berechtigungen, Links, ACLs und erweiterte Attribute erhalten kann.

Eine typische Kopie im Archivstil ist:

rsync -aHAX --info=progress2   /DATA/oldraid/   /DATA/offload/

Führen Sie die Kopie in tmux oder ein anderes dauerhaftes Terminal, wenn eine SSH-Trennung den Vorgang andernfalls unterbrechen würde.

Sicherung überprüfen, bevor Sie fortfahren

Verlassen Sie sich nicht nur auf die abschließende rsync-Meldung. Vergleichen Sie die Dateianzahl und prüfen Sie die Größen der wichtigsten Verzeichnisse:

find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l

du -sh /DATA/oldraid/*
du -sh /DATA/offload/*

Bei unersetzlichen Daten ist eine zweite, unabhängige Sicherung vorzuziehen. RAID ist selbst kein Backup.

Letzte Möglichkeit: Auslagern, alte RAID-Metadaten entfernen, in der Benutzeroberfläche neu erstellen

Der ursprüngliche Autor aus der Community wollte, dass das wiederhergestellte Array wieder normal über die ZimaOS-Benutzeroberfläche verwaltet werden kann. Als letzte Möglichkeit verwendete er folgendes Verfahren:

Überprüfen Sie das alte Array schreibgeschützt.
Kopieren Sie alle Daten auf ein externes Laufwerk.
Überprüfen Sie die Kopie.
Stoppen Sie das alte md-Array.
Entfernen Sie die alten RAID-Metadaten.
Erstellen Sie über die ZimaOS-Speicheroberfläche ein neues RAID 1.
Stellen Sie die kopierten Dateien wieder her.
Überprüfen Sie die wiederhergestellten Daten.

Dieses Verfahren zerstört absichtlich die alten RAID-Metadaten. Nach diesem Schritt ist die ausgelagerte Kopie Ihre Wiederherstellungsquelle. Verwenden Sie diesen Ansatz nicht, wenn die Kopie unvollständig ist oder Sie sich über die Gerätezuordnung nicht sicher sind.

Der unumkehrbare Befehl im Ausgangsverfahren

Das von der Community verwendete Verfahren:

mdadm --zero-superblock /dev/sda /dev/sdb

Dies ist kein Befehl zur Fehlerbehebung. Er entfernt RAID-Metadaten von den angegebenen Datenträgern. Ein falscher Gerätepfad kann zu erheblichem Datenverlust führen.

Aus diesem Grund empfiehlt diese Seite nicht, den Befehl allein deshalb auszuführen, weil die ZimaOS-Benutzeroberfläche ein RAID nicht erkennt. Wiederherstellen local-storage.db, überprüfen Sie zunächst das aktuelle Wiederherstellungsverhalten von ZimaOS und wenden Sie sich an den Support, wenn das Array wichtige Daten enthält.

Warum das Array über die ZimaOS-Benutzeroberfläche neu erstellen?

Ziel des Quell-Workflows war ein Speicherpool, der normal von ZimaOS verwaltet wird, statt eines dauerhaft manuell zusammengesetzten md-Geräts außerhalb der Speicheroberfläche.

Nachdem die alten Daten sicher ausgelagert und die Laufwerke absichtlich zurückgesetzt wurden, verwenden Sie die aktuelle Speicheroberfläche, um RAID 1 zu erstellen, und warten Sie, bis die erste Synchronisierung abgeschlossen ist.

Die Dateien im neuen Pool wiederherstellen

Nachdem der neue Pool erstellt und eingebunden wurde, stellen Sie die Daten vom Auslagerungslaufwerk wieder her:

rsync -aHAX --info=progress2   /DATA/offload/   /media/Storage/

Ersetzen /media/Storage mit dem tatsächlichen, auf Ihrem System angezeigten Zielpfad.

Den wiederhergestellten Pool überprüfen

find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstat

Lassen Sie das Auslagerungslaufwerk unangetastet, bis die RAID-Synchronisierung abgeschlossen ist und Sie den normalen Zugriff über die ZimaOS-Dateischnittstelle sowie die von den Daten abhängigen Anwendungen überprüft haben.

local-storage.db vor der nächsten Neuinstallation sichern

Am einfachsten ist die Wiederherstellung, wenn sie im Voraus vorbereitet wurde. Bewahren Sie eine aktuelle Kopie von Folgendem auf:

/ZimaOS-HD/.casaos/db/local-storage.db

außerhalb des Systemlaufwerks. Die offizielle Dokumentation enthält jetzt eine direkte Wiederherstellungsanleitung für diese Datei.

Welchen Wiederherstellungspfad sollten Sie wählen?

Situation	Empfohlene Aktion
Sie haben local-storage.db gesichert.	Verwenden Sie die offizielle Methode zur Datenbankwiederherstellung.
Das alte Systemlaufwerk ist noch lesbar.	Stellen Sie local-storage.db wieder her, bevor Sie Änderungen an den RAID-Laufwerken vornehmen.
Keine Datenbanksicherung, RAID-Metadaten sehen intakt aus	Unterbrechen Sie destruktive Aktionen und holen Sie Support oder Beratung zur Datenwiederherstellung ein.
Sie verfügen über eine vollständige, verifizierte ausgelagerte Kopie und möchten absichtlich ein sauber von der Benutzeroberfläche verwaltetes Array erstellen.	Ziehen Sie die Community-Methode zum Auslagern, Neuerstellen und Wiederherstellen in Betracht.
Die RAID-Mitglieder weisen nicht übereinstimmende oder beeinträchtigte Metadaten auf.	Halten Sie an und nutzen Sie die Anleitung eines Spezialisten zur Datenwiederherstellung.

FAQ zur RAID-Wiederherstellung in ZimaOS

Löscht die Neuinstallation von ZimaOS automatisch die RAID-Daten?

Nein. Die Neuinstallation des Systemlaufwerks unterscheidet sich von der Formatierung der RAID-Mitgliedslaufwerke. Die Speicherkonfiguration kann verloren gehen, während RAID-Metadaten und Daten auf den Mitgliedslaufwerken erhalten bleiben.

Soll ich auf „RAID erstellen“ klicken, wenn die alten Laufwerke als unbenutzt angezeigt werden?

Erst, wenn Sie bestätigt haben, dass keine vorhandenen Daten wiederhergestellt werden müssen. Das Erstellen eines neuen RAID kann destruktiv sein.

Was ist die sicherste Wiederherstellungsmethode, wenn ich local-storage.db gesichert habe?

Verwenden Sie die aktuelle offizielle ZimaOS-Anleitung, um diese Datenbank wiederherzustellen und neu zu starten.

Ist das Überschreiben des mdadm-Superblocks mit Nullen sicher?

Die RAID-Metadaten werden dabei absichtlich zerstört. Verwenden Sie dies nur als Teil eines verifizierten Wiederherstellungsplans, nachdem die Daten sicher an einen anderen Ort kopiert wurden.