完全な復元を必要とせずにZFSディスクを切り離して再接続することは可能ですか？
合計4つのドライブを持つZFSミラー化プールがあります。 2台のドライブは、オフサイトバックアップのローテーションに使用することを目的としています。最初の再同期後、ディスクをdetach以降attachして、増分再同期のみを実行できると予想していました。ただし、テストでは、接続されているディスクには、ほぼすべてのプール内容が含まれているわけではありません。
offline/onlineアプローチを使用すると、ディスクを完全に再構築するのではなく、ディスクを更新するだけで望ましい結果が得られますか？または、期待どおりにこの作業を行うには、各バックアップディスクを1ディスクプールとして使用し、最新のスナップショットを最新の状態にする必要があるときはいつでもそれに最新のスナップショットをsendingするなど、まったく異なることを行う必要があります。 ？
さらなる実験の後、私は公正な解決策を見つけましたが、それは大きなトレードオフを伴います。 offlineされたが切り離されていないディスクは、後でインクリメンタル再同期操作のみでオンラインに戻すことができます（ " デバイスがオンラインになると、プールに書き込まれたデータはすべて新しく利用可能なデバイスと再同期されます。 "）。私のテストでは、これにより3ディスクミラーの再同期時間が28時間から30分強に短縮され、約40GBのデータ差分が生じます。
トレードオフは、オフラインのディスクを含むすべてのプールに劣化のフラグが付けられることです。少なくとも2つのオンラインディスク（ミラープール内）がまだある場合、これは事実上警告です-完全性と冗長性はそのまま残ります。
他の人が述べたように、この全体的なアプローチは理想からはほど遠いです-スナップショットをリモートプールに送信する方がはるかに適していますが、私の場合は実現可能ではありません。
要約すると、プールからディスクを削除し、後で完全な再同期化を必要とせずにディスクを元に戻す必要がある場合、私がお勧めするアプローチは次のとおりです。
- プール内のディスクをオフラインにします：
zpool offline pool disk - ドライブをスピンダウンします（物理的にプルする場合）：
hdparm -Y /dev/thedisk - ドライブをオフラインにしたまま、プールを機能低下状態のままにします
- ディスクをプールに戻すには：
zpool online pool disk
また、これはまだテストされていないため、デルタ再同期化操作が正確ではない可能性があります。 「ライブ」プールまたはオフラインディスク、あるいはその両方で問題が発生する可能性があります。それが起こった場合は更新しますが、今のところ、このアプローチを実験します。
ZFSアレイを壊してオフサイトのディスクを「回転」させる道を進んではいけません。ご覧のように、再構築時間は長く、再同期プロセスはデータセットのsedサイズを読み取り/検証します。
可能であれば、スナップショットとリモートシステムへのデータの送信は、クリーンで邪魔にならないアプローチです。専用の単一ディスクプール、それへのコピー、およびzpool export/import ...のプロセスを実行できると思いますが、あまり洗練されていません。
2015年10月15日に更新：今日、_zpool split_コマンドを発見しました。これは、新しいプール（新しい名前）を既存のプールから分割しますプール。 splitは、offlineおよびdetachよりもすっきりしています。これは、両方のプールが同じシステム上に存在し、個別にスクラブされるためです。新しいプールは、システムから外す前に、きれいに（適切に）_export[ed]_にすることもできます。
（私の元の投稿は以下の通りです。）
警告！このページのさまざまなコメントは、ドライブを_zpool detach_できる可能性がある（または可能性がある）ことを意味し、ドライブを再接続します含まれているデータにアクセスします。
ただし、 このスレッド （および私自身の実験）によれば、_zpool detach_は、切り離されたドライブから「プール情報」を削除します。つまり、detachは、ドライブの迅速な再フォーマットのようなものです。 detachを実行した後もドライブに大量のデータが残っている可能性がありますが、ドライブを再マウントしてデータを使用可能なファイルシステムとして表示することは実質的に不可能です。
その結果、_zpool import_は破棄されたプールを回復できると私は信じているので、detachはdestroyよりも破壊的であるように見えます！
detachはnota umount、nora _zpool export_です、nor_zpool offline_。
私の実験では、最初にデバイスを_zpool offline_し、次に同じデバイスを_zpool detach_した場合、プールの残りの部分は、デバイスが存在していたことを忘れます。ただし、デバイス自体は_offline[d]_になる前は_detach[ed]_であったため、デバイス自体にdetachが通知されることはありません。したがって、デバイス自体はまだプール情報を保持しており、別のシステムに移動してから_import[ed]_（機能低下状態）に移動できます。
detachに対する保護を強化するために、offlineコマンドの後で、detachコマンドを発行する前に、物理的にデバイスのプラグを抜くこともできます。
このoffline、次にdetach、次にimportプロセスを使用してプールをバックアップしたいと思います。元のポスターと同様に、4台のドライブを使用し、2台を常時ミラーで使用し、2台を月次のローテーションのオフサイト（およびオフライン）バックアップに使用する予定です。オフサイトに輸送する前に、別のシステムにインポートしてスクラブすることにより、各バックアップを検証します。元のポスターとは異なり、毎月バックアップドライブ全体を書き換えてもかまいません。実際、私は新鮮な部分を持つために完全な書き換えを好みます。
同じマシンで、ミラー内の2つのドライブで新しいプールを作成してみましたか？次に、作業プールにスナップショットを作成し、そのスナップショットを新しいプールに送信して繰り返します。次のスナップショットの送信は増分になります。これは同じシステム/サーバー/マシン内のプールであるため、「リモートシステムへのデータの送信」とは異なります。このセットアップでは、zpool split/offline/detach/attachを適用できますが、2番目の（コピー）プールでのみ実行でき、ソースプールでは実行できません。