ZimaOS RAID 1 nach dem Austausch beider Festplatten durch größere Laufwerke erweitern: Community-Workflow mit mdadm und Btrfs

Die Quelle belegt, dass das Ersetzen beider RAID-1-Mitglieder durch größere Festplatten das nutzbare Dateisystem nicht automatisch vergrößert. Ein Benutzer ersetzte erfolgreich nacheinander zwei 500-GB-Festplatten durch 1-TB-Festplatten und ließ ZimaOS nach jedem Austausch das Array wiederaufbauen. Zu diesem Zeitpunkt hatten beide physischen Mitglieder 1 TB, aber das RAID-Gerät und das Btrfs-Dateisystem stellten weiterhin nur die alte Kapazität von 500 GB bereit.

Unter ZimaOS+ 1.5.4 schloss dieser Benutzer die Erweiterung anschließend per SSH mit mdadm --grow /dev/md0 --size=max, warteten auf die daraus resultierende Wiederherstellung/Resynchronisation und führten schließlich btrfs filesystem resize max für das eingebundene Dateisystem aus. Sie berichteten, dass die GUI und df und zeigte anschließend die größere Kapazität an. Dies ist eine starke Bestätigung durch die Community, aber weiterhin ein manueller CLI-Arbeitsablauf und kein aktuelles IceWhale-GUI-Verfahren.

Sichern Sie Ihre Daten, bevor Sie mit der Kapazitätserweiterung beginnen

RAID 1 schützt vor dem Ausfall eines Mitglieds, nicht jedoch vor Bedienfehlern, Beschädigungen der Array-Metadaten, Fehlern am Dateisystem oder einem zweiten Festplattenproblem während des Wiederaufbaus.

Ersetzen Sie jeweils nur ein RAID-Mitglied

1. Herunterfahren;
2. Ersetzen Sie die erste alte Festplatte durch die größere Festplatte;
3. starten;
4. Verwenden Sie ZimaOS Recovery zum Wiederaufbau;
5. Warten Sie, bis die Wiederherstellung vollständig abgeschlossen ist.

Für das zweite Mitglied wiederholen

Erst nach Abschluss des ersten Wiederaufbaus fuhr der Benutzer das System herunter und ersetzte die zweite Festplatte. Anschließend führte er die Wiederherstellung über die GUI erneut aus und wartete, bis sie vollständig abgeschlossen war.

Zu diesem Zeitpunkt war das Array auf zwei größeren physischen Geräten fehlerfrei, hatte aber weiterhin die historische Größe der Mitglieder.

Der Community-Benutzer vergrößerte anschließend das mdadm-Array

Der Quellbefehl lautete:

sudo mdadm --grow /dev/md0 --size=max

Sie überprüften die neue Array-Geometrie mit mdadm --detail und wartete, bis der neue Wiederherstellungs-/Resynchronisationsvorgang abgeschlossen war.

Gehen Sie niemals davon aus, dass Ihr Array /dev/md0; identifizieren Sie zunächst das tatsächliche Array.

Anschließend musste das Btrfs-Dateisystem erweitert werden

Die Quelle endete mit:

sudo btrfs filesystem resize max /your/mounted/filesystem

Verwenden Sie den tatsächlich eingebundenen Btrfs-Pfad, anstatt den Platzhalter wörtlich zu kopieren.

Warum zwei Schritte zur Größenänderung erforderlich waren

• das Linux-md-RAID-Gerät;
• das darauf liegende Btrfs-Dateisystem.

Beide müssen die größere Größe bereitstellen, bevor Benutzer die zusätzliche Kapazität sehen.

Behandle dies als versionsspezifisches Community-Verfahren

Der Quellbenutzer verwendete ausdrücklich ZimaOS+ 1.5.4. Das aktuelle ZimaOS ist neuer, und das Verhalten der Speicherverwaltung kann sich ändern. Bevor Sie manuelle mdadm --grow Überprüfen Sie bei produktivem Speicher, ob die Benutzeroberfläche weiterhin keinen unterstützten Erweiterungspfad bietet, und erwägen Sie, den IceWhale-Support nach dem aktuellen Verfahren zu fragen.

RAID-Zustand vor jedem physischen Austausch überprüfen

Bestätigen Sie vor dem Austausch des ersten Laufwerks – und erneut vor dem Austausch des zweiten –, dass das Array fehlerfrei und vollständig synchronisiert ist. Wenn Sie den zweiten Austausch beginnen, bevor die erste Wiederherstellung abgeschlossen ist, verlieren Sie die Redundanz, auf die Sie während der Aufrüstung angewiesen sind.

Notieren Sie die Seriennummern der Mitglieder, damit das physisch entfernte Laufwerk dem von ZimaOS angezeigten logischen Mitglied entspricht.

Ersatzlaufwerke benötigen ausreichend reale Kapazität

Laufwerke mit nominell gleicher Kapazität können sich geringfügig in der Anzahl der nutzbaren Sektoren unterscheiden. Am sichersten ist eine Erweiterung mit Ersatzlaufwerken, die eindeutig größer als die alten Mitglieder und mindestens gleich groß wie einander sind.

Wenn das zweite „1-TB“-Laufwerk geringfügig kleiner als das erste ist, funktioniert der md-Erweiterungs-/Wiederherstellungsschritt möglicherweise nicht wie erwartet.

Mit mehr als einem Resynchronisierungszyklus rechnen

Im Quellablauf wurde nach dem ersten physischen Austausch eine Wiederherstellung durchgeführt, nach dem zweiten erneut, und anschließend nach dem mdadm --grow. Das bedeutet, dass eine Kapazitätserweiterung deutlich länger dauern kann als der einfache Austausch zweier Laufwerke.

Halten Sie das NAS während jeder Wiederherstellungsphase an einer zuverlässigen Stromversorgung und vermeiden Sie unnötige Neustarts.

Am Ende sowohl das Blockgerät als auch das Dateisystem überprüfen

Überprüfen Sie das Ergebnis nach der abschließenden Btrfs-Vergrößerung auf mehr als einer Ebene:

• mdadm --detail – md-RAID-Geometrie;
• df -h oder Btrfs-Dateisystemwerkzeuge – nutzbare Dateisystemkapazität;
• ZimaOS-Speicheroberfläche – erwartete Poolgröße und fehlerfreier Zustand.

Wenn eine Ebene weiterhin die alte Größe anzeigt, halten Sie an und untersuchen Sie das Problem, anstatt blind weitere Erweiterungsbefehle auszuführen.

FAQ zur RAID-1-Erweiterung

Kann ein größeres Laufwerk die RAID-1-Kapazität sofort erhöhen?

Nein. Der Spiegel bleibt durch das kleinere Mitglied und die historische Array-Geometrie begrenzt.

Hat der Austausch beider kleinerer Laufwerke die Kapazität in der Quelle automatisch erhöht?

Nein. Der Benutzer musste weiterhin das md-Array erweitern und anschließend Btrfs vergrößern.

War der manuelle Erweiterungsablauf durch die Quelle bestätigt?

Ja, von einem ZimaOS+-1.5.4-Benutzer. Es wurde nicht als offizielles Verfahren von IceWhale veröffentlicht.