2 台の Linux マシン間でポータブル暗号化 ZFS フォーマット ドライブを共有する際の問題

2 台の Linux マシン間でポータブル暗号化 ZFS フォーマット ドライブを共有する際の問題

私は 2 台の Linux (NixOS) マシンを持っており、暗号化された ZFS 形式のポータブル USB ハード ドライブを共有したいと考えています。 1 台のマシンでは問題なく動作しましたが、2 台目のマシンにマウントしようとしたときに、ドライブ上の ZFS ファイルシステムが破壊された可能性があります。

USB ドライブをあるマシンから別のマシンに移動する前に、zpool をエクスポートしてアンマウントしました。2 台目のマシンのドライブから zpool をインポートできることを期待していましたが、ZFS の zpool の概念を誤解していた可能性があります。、、などのさまざまな組み合わせを使用しても、2 台目のマシンで ZFS ドライブをまったく認識できませんでした。zpool listドライブzpool import -aは間違いzpool import -Dなく として表示されていました/dev/sdbが、この 2 台目のマシンの ZFS の自動検出では、不可解な理由で単に無視されていました。

結局、sudo zpool create z /dev/sdbzpool は完全に仮想的なもので、このマシンにミラーリングする必要があると考え、単純な を実行しましたが、このコマンドは、このドライブ上の元の ZFS ファイルシステムを警告なしに上書きしたと思います。ドライブは空の暗号化されていないファイルシステムになり、そこからデータを回復できるかどうかさえわかりません。幸い、バックアップがあったので、完全に失われるわけではありません。

2つの質問:

  1. 既存の vdev 上に新しい zpool を作成すると、そのデバイス上の以前の ZFS ファイルシステムは不可逆的に破壊されますか?

  2. 既存の暗号化された ZFS ドライブ zpool を、圧縮、暗号化、データセットなどの元の zpool 構成オプションをすべてインポートしながら、あるマシンから別のマシンにインポートするにはどうすればよいでしょうか。そうでない場合zpool import、それは何ですか。

答え1

実験によって最初の質問に答えたと思います。はい、zpool create影響を受ける vdev 上の既存のプールをすべて上書きします。

このプールを共有するシステム間の互換性を確保するために作業していることを考えると、zpool 構造の仕組みが正しいこと、およびテストの成功を妨げる可能性のある根本的な障害がないことが確実になるまで、暗号化を控えることをお勧めします。

そうは言っても、ZFS プールをシステム間で移植可能にするために必要な条件の 1 つは、プールを構成するブロック デバイス (プール メタデータにエンコードされている) が、プールをインポートするすべてのシステムで一意でなければならないことです。このため、/dev/sdbなどの物理デバイスをそのまま使用するのは賢明ではありません。使用するドライブごとにパーティションを作成し、使用するパーティションごとに一意のラベルを割り当てる方がよいでしょう。ドライブのシリアル番号は、プール メタデータだけでなく出力でも電子的に表示され、blkid物理ドライブ シャーシを検査するときに人間が確認できるため、多くの場合、便利な文字列です。

したがって、ハード ドライブのシリアル番号が の場合6SL0CTD、そのドライブにパーティションを作成し、 というラベルを付ける必要がありますzfs-data-6SL0CTD。次に、その論理デバイス (可変の可能性がある物理デバイスではなく) を参照するプールを作成します。

# zpool create tank /dev/disk/by-partlabel/zfs-data-6SL0CTCD

また、のマニュアルページを読んでくださいzpool import。何をインポートしているのか(またはなぜインポートされないのか)がわからない場合に使用できる非破壊的なツールが多数あることに注意してください。

パラメータなしの場合:

# zpool import

インポート可能なプールが表示されます。テストケースは手元にありませんが、インポート可能なプールも表示されると思います。できない通常は、デバイスが見つからないか故障しているために、インポートできません。デバイスが「見つからない」原因の 1 つは、プールのメタデータで /dev/sdb が使用されると指定されているものの、ホストにはすでに /dev/sdb があり、そのデバイスにはプールに一致するメタデータが含まれていないことです。繰り返しますが、パーティション ラベルを割り当て、パーティション ラベルのみに基づいてプールを作成することが重要なのはこのためです。パーティション ラベルが存在する場合、プールは見つかり、物理的なパーティションが表示されるデバイス。

# zpool import -N tank

プールをインポートしますtankが、そこからファイルシステムをマウントしません。これは、プールの 2 番目のレベルのチェックとして使用できます。何もマウントされませんが、プールの統計を検査したり、プールをscrubベッドにしたりすることができます。

明確なデバイス名を使用するようにプールを正しく作成すると、後からこれがなぜ重要であるかがわかります。

zpool status -Pプール内のすべてのデバイスの完全な論理パスが表示されます。

# 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

zpool status -L逆に、物理的なプール内のすべてのデバイスのデバイス名:

# 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

物理デバイス ノードの代わりにパーティション ラベルを使用すると、出力はzpool status -Pプールをインポートするすべてのマシンで同一になりますが、出力はzpool status -L異なる場合があります。そのため、zpool createコマンドは、プールをインポートする必要がある可能性のあるすべてのマシンで一意であることが保証される非バリアント論理デバイスで記述する必要があります。

プールを明確なデバイス名で構造化したら、プールをインポートする必要があるホスト上に比較的類似した ZFS スタックがあると仮定すると、zpool に暗号化を適用するのは簡単なはずです。

関連情報