Leitfaden zur Migration von ZFS-Datasets: Daten verschieben, ohne Containerpfade zu ändern

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Der sichere Ansatz besteht darin, Replikation, Verifizierung und das atomare Umschalten des ursprünglichen Einhängepunkts mit einem beibehaltenen Rollback-Dataset als eine Abfolge beobachtbarer Prüfungen zu behandeln, nicht als einen einzelnen Befehl.

Bei ZFS-Datasets, die einen Home-Server-Container-Stack unterstützen, besteht das praktische Risiko darin, ein ZFS-Dataset verschieben zu müssen, während die von Containern verwendeten Bind-Mount-Pfade erhalten bleiben. Erfassen Sie die aktuelle Identität und den Wiederherstellungspunkt, beginnen Sie mit dem am wenigsten invasiven Unterscheidungskriterium, interpretieren Sie bestandene und fehlgeschlagene Ergebnisse, bevor Sie eine weitere Variable ändern, und brechen Sie ab, sobald der Speicher instabil wird oder die einzige wiederherstellbare Kopie offengelegt würde. Der folgende Ablauf endet erst, wenn die ursprüngliche Arbeitslast erfolgreich ausgeführt wird oder die Beweislage eine Eskalationsgrenze erreicht.

Dataset und Pfadvertrag inventarisieren

Erfassen Sie das Quelldataset, untergeordnete Datasets, Snapshots, den Einhängepunkt, den canmount-Wert, die Verschlüsselungswurzel, Quotas, Reservierungen, das ACL-Verhalten und jeden Container-Bind-Mount, der darin liegt. Der Vertrag ist der Host-Pfad, den die Container sehen; Pool- und Dataset-Name können sich unterhalb dieses Pfads ändern.

ZFS-Replikation kann Snapshots und Eigenschaften bewahren, daher erfordert ein rekursiver Stream eine gezielte Prüfung der Eigenschaften statt eines blinden Empfangs. Eine unabhängige Migration mit ZFS Send und Receive zeigt, wie Send und Receive für die interne Dataset-Migration verwendet werden und warum die Zielhierarchie vor dem Umschalten überprüft werden sollte.

Erstellen Sie vor der Migration ein aktuelles externes Backup oder weisen Sie eine vorhandene Wiederherstellung nach. Brechen Sie ab, wenn die Quelle verborgene untergeordnete Datasets, eine unbekannte Abhängigkeit von einem Verschlüsselungsschlüssel oder einen Einhängepunkt aufweist, der ein anderes aktives Dataset überlagert; diese Bedingungen können dazu führen, dass ein korrekter Stream am falschen Ort eingehängt wird.

Die erste Kopie empfangen, ohne sie über die Produktion zu mounten

Erstellen Sie einen rekursiven Snapshot wie zfs snapshot -r oldpool/apps@move-0 und senden Sie ihn an ein Zieldataset, das mit deaktiviertem Mounten oder einem temporären Einhängepunkt empfangen wird. Verwenden Sie die für Ihre Verschlüsselungs- und Eigenschaftsanforderungen geeigneten Optionen; gehen Sie nicht davon aus, dass ein roher verschlüsselter Stream und ein entschlüsselter Empfang dasselbe Schlüsselverhalten haben.

Vergleichen Sie nach dem Empfang zfs list -r -t filesystem,snapshot und zfs get -r mountpoint,canmount,encryptionroot,quota,reservation auf beiden Bäumen. Eine Forendiskussion über replizierte Einhängepunkt-Eigenschaften veranschaulicht, warum replizierte Einhängepunkt-Eigenschaften eine ansonsten erfolgreiche Migration überraschen können.

Die erste Kopie ist erfolgreich, wenn Dataset- und Snapshot-Abstammung übereinstimmen und das Ziel vom Produktionspfad isoliert bleibt. Wenn es über der Quelle eingehängt wird oder für Container sichtbare Dateien verändert, exportieren Sie das Ziel oder hängen Sie es aus und korrigieren Sie die Eigenschaften, bevor Sie einen inkrementellen Send durchführen.

Die Schreib Lücke schließen und den Einhängepunkt umschalten

Erstellen Sie einen weiteren Snapshot der Quelle und senden Sie die inkrementelle Differenz, während die Anwendung noch läuft. Stoppen Sie für das endgültige Umschalten alle Schreibvorgänge, bestätigen Sie, dass kein Prozess Dateien unter dem Bind-Mount-Pfad geöffnet hat, erstellen Sie einen letzten Snapshot und senden Sie nur dieses Delta. Begrenzen Sie die Ausfallzeit auf die abschließende Synchronisierung und das Umschalten des Pfads.

Setzen Sie die Quelle auf einen nicht produktiven Einhängepunkt oder canmount=noauto, weisen Sie dann dem Ziel den ursprünglichen Host-Pfad zu und mounten Sie es. Lassen Sie niemals zwei Datasets denselben Einhängepunkt beanspruchen. Starten Sie die Datenbank und abhängige Dienste vor dem Anwendungs-Frontend, damit Fehler der richtigen Ebene zugeordnet werden können.

Wenn der abschließende Send fehlschlägt, mounten Sie die Quelle wieder am ursprünglichen Pfad und starten Sie den Stack neu; mischen Sie keine neuen Schreibvorgänge über beide Kopien. Die Rollback-Bedingung ist eindeutig: Die Quelle bleibt intakt, und auf dem Ziel wird kein Produktionsschreibvorgang akzeptiert, bevor der abschließende Stream und die Eigenschaftsprüfungen erfolgreich waren.

Container am unveränderten Pfad validieren

Überprüfen Sie die Bind-Mounts über die Container-Laufzeitumgebung, öffnen Sie repräsentative Dateien, erstellen und entfernen Sie über die Anwendung eine temporäre Datei und bestätigen Sie Eigentümer, ACLs, erweiterte Attribute und die Meldung des freien Speicherplatzes. Starten Sie den Stack zweimal neu und überprüfen Sie, dass ZFS gemountet wird, bevor die Container starten.

Führen Sie gemäß Ihrem Wartungsplan einen Scrub oder eine andere Pool-Zustandsprüfung durch, verwenden Sie diese jedoch nicht als alleinigen Nachweis der Migration. Vergleichen Sie Snapshot-GUIDs oder ein repräsentatives Hash-Manifest, stellen Sie ein kleines Element wieder her und verwenden Sie den ZimaSpace-Test, um zu prüfen, ob die ZFS-Replikation nach einer Unterbrechung fortgesetzt werden kann, bevor Sie die Quellabstammung außer Betrieb nehmen.

Behalten Sie die Quelle schreibgeschützt, bis mindestens ein normaler Backup- und Anwendungszyklus erfolgreich abgeschlossen wurde. Nehmen Sie sie erst außer Betrieb, wenn die Container die ursprünglichen Pfade verwenden, geplante Jobs auf das neue Dataset zielen, die Replikation von der vorgesehenen Abstammung aus fortgesetzt wird und kein Rollback mehr erforderlich ist; andernfalls setzen Sie den Einhängepunkt zurück und bewahren Sie beide Historien auf.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.