Ich habe zwei Linux-Rechner (NixOS), die ich gerne mit einer verschlüsselten, ZFS-formatierten, portablen USB-Festplatte teilen möchte. Bei einem einzelnen Rechner hat das problemlos funktioniert, aber beim Versuch, es auf meinem zweiten Rechner zu mounten, habe ich möglicherweise das ZFS-Dateisystem auf der Festplatte zerstört.
Bevor ich das USB-Laufwerk von einer Maschine auf die andere verschoben habe, habe ich den Zpool exportiert, um ihn zu demontieren. Ich hatte gehofft, den Zpool vom Laufwerk auf der zweiten Maschine importieren zu können, aber vielleicht habe ich das Zpool-Konzept von ZFS falsch verstanden. Ich konnte mit verschiedenen Kombinationen von zpool list, zpool import -a, zpool import -D, usw. nicht erreichen, dass meine zweite Maschine das ZFS-Laufwerk überhaupt erkennt. Das Laufwerk wurde definitiv als angezeigt /dev/sdb, aber die automatische Erkennung von ZFS auf dieser zweiten Maschine ignorierte es aus mysteriösen Gründen einfach.
Schließlich habe ich einen einfachen Befehl ausgeführt sudo zpool create z /dev/sdb, weil ich dachte, der Zpool sei eine rein virtuelle Sache, die ich auf dieser Maschine spiegeln müsste, aber ich glaube, dieser Befehl hat die ursprünglichen ZFS-Dateisysteme auf diesem Laufwerk ohne Warnung überschrieben. Das Laufwerk ist jetzt ein leeres, unverschlüsseltes Dateisystem und ich bin mir nicht sicher, ob es überhaupt möglich ist, meine Daten davon wiederherzustellen. Zum Glück hatte ich Backups, also ist es kein Totalverlust.
Zwei Fragen:
Werden durch das Erstellen eines neuen Zpools auf einem vorhandenen Vdev alle vorherigen ZFS-Dateisysteme auf diesem Gerät unwiderruflich zerstört?
Wie kann man ein vorhandenes verschlüsseltes ZFS-Laufwerk zpool von einer Maschine auf eine andere importieren und dabei alle ursprünglichen zpool-Konfigurationsoptionen wie Komprimierung, Verschlüsselung, Datensätze usw. importieren? Wenn nicht
zpool import, was ist es dann?
Antwort1
Ich gehe davon aus, dass Sie Ihre erste Frage anhand Ihres Experiments beantwortet haben: Ja, durch Ausführen eines zpool createClobbers werden alle vorhandenen Pools auf den betroffenen vdevs überschrieben.
Da Sie an der Gewährleistung der Kompatibilität zwischen den Systemen arbeiten, für die Sie diesen Pool gemeinsam nutzen möchten, würde ich Ihnen empfehlen, auf die Verschlüsselung zu verzichten, bis Sie sicher sind, dass die Mechanik der Zpool-Struktur richtig ist und dass keine zugrunde liegenden Blockaden vorliegen, die den Erfolg Ihrer Tests beeinträchtigen könnten.
Eine der notwendigen Voraussetzungen für die Portabilität von ZFS-Pools zwischen verschiedenen Systemen ist, dass die Blockgeräte, aus denen der Pool besteht (und die in den Pool-Metadaten codiert sind), auf allen Systemen, in die der Pool importiert werden soll, eindeutig sein müssen. Daher ist es nicht ratsam, bloße physische Geräte wie /dev/sdbusw. zu verwenden. Besser ist es, auf jedem zu verwendenden Laufwerk eine Partition zu erstellen und jeder verwendeten Partition eine eindeutige Bezeichnung zuzuweisen. Die Seriennummer des Laufwerks ist häufig eine praktische Zeichenfolge, da sie nicht nur in den Pool-Metadaten, sondern auch in der blkidAusgabe elektronisch sichtbar ist und bei der Überprüfung des physischen Laufwerkgehäuses von Menschen erkannt werden kann.
Wenn die Seriennummer der Festplatte also lautet 6SL0CTD, sollten Sie auf dieser Festplatte eine Partition erstellen und sie mit dem Namen versehen zfs-data-6SL0CTD. Erstellen Sie dann den Pool, der auf dieses logische Gerät verweist (anstelle des möglicherweise variablen physischen Geräts):
# zpool create tank /dev/disk/by-partlabel/zfs-data-6SL0CTCD
Lesen Sie außerdem die Manpage für zpool importund beachten Sie, dass es viele nicht-destruktive Tools gibt, die Sie verwenden können, wenn Sie nicht sicher sind, was Sie importieren (oder warum der Import nicht funktioniert):
Ohne Parameter:
# zpool import
zeigt Ihnen alle Pools an, die möglicherweise importiert werden können. Ich habe keinen Testfall zur Hand, aber ich glaube, es werden auch Pools angezeigt, diekann nichtimportiert werden, normalerweise aufgrund fehlender oder ausgefallener Geräte. Eine Ursache für ein „fehlendes“ Gerät kann sein, dass die Pool-Metadaten besagen, dass /dev/sdb verwendet werden soll, der Host jedoch bereits über ein /dev/sdb verfügt und dieses Gerät keine Metadaten enthält, die mit dem Pool übereinstimmen. Aus diesem Grund ist es wiederum wichtig, Partitionsbezeichnungen zuzuweisen und Pools ausschließlich auf der Grundlage von Partitionsbezeichnungen zu erstellen. Wenn diese Partitionsbezeichnung vorhanden ist, wird der Pool gefunden und es spielt keine Rolle, wasphysischGerät, auf dem diese Partition angezeigt wird.
# zpool import -N tank
Importiert den Pool tank, mountet aber keine Dateisysteme daraus. Dies kann als Überprüfung des Pools auf zweiter Ebene verwendet werden. Obwohl nichts gemountet ist, können die Statistiken des Pools überprüft, der Pool gemountet scrubusw. werden.
Wenn Sie Ihren Pool richtig erstellt haben, sodass er eindeutige Gerätenamen verwendet, können Sie im Nachhinein erkennen, warum dies wichtig sein kann.
zpool status -Pzeigt den vollständigen, logischen Pfad aller Geräte im Pool an:
# zpool status -P
pool: tank
state: ONLINE
scan: scrub repaired 0B in 21h34m with 0 errors on Sun Oct 10 21:58:23 2021
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
/dev/disk/by-partlabel/zfs-data-6SL0CTCD ONLINE 0 0 0
errors: No known data errors
Umgekehrt zpool status -Lzeigt sich diephysischGerätename aller Geräte im Pool:
# zpool status -L
pool: tank
state: ONLINE
scan: scrub repaired 0B in 21h34m with 0 errors on Sun Oct 10 21:58:23 2021
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
sdb1 ONLINE 0 0 0
errors: No known data errors
Das Endergebnis der Verwendung von Partitionsbezeichnungen anstelle von physischen Geräteknoten ist, dass die Ausgabe zpool status -Pauf allen Maschinen, die den Pool importieren, identisch ist, obwohl die Ausgabe zpool status -Ldurchaus unterschiedlich sein kann. Aus diesem Grund zpool createmuss der Befehl in Form von nicht variantenreichen logischen Geräten geschrieben werden, die auf allen Maschinen, die den Pool möglicherweise importieren müssen, garantiert eindeutig sind.
Sobald Sie den Pool hinsichtlich eindeutiger Gerätenamen strukturiert haben, sollte die Anwendung der Verschlüsselung auf den Z-Pool unkompliziert sein, vorausgesetzt, dass Sie auf den Hosts, die den Pool importieren können müssen, einigermaßen ähnliche ZFS-Stacks haben.