完全な復元を必要とせずにZFSディスクを切り離して再接続することは可能ですか？

合計4つのドライブを持つZFSミラー化プールがあります。2台のドライブは、オフサイトバックアップのローテーションに使用することを目的としています。私の期待は、最初の再同期detach後attach、ディスクを作成し、後で増分再同期のみを実行できるようにすることですが、テストでは、接続されているディスクにほぼすべてのプールが含まれているかどうかに関係なく、完全再同期を実行しているように見えます内容。

offline/ onlineアプローチを使用すると、完全に再構築するのではなく、ディスクを更新するだけで望ましい結果が得られますか？または、期待どおりにこの作業を行うには、各バックアップディスクを1ディスクプールとして使用しsend、最新のスナップショットを最新の状態にする必要があるときにいつでもそれにスナップショットを書き込むなど、まったく異なることを行う必要がありますか？

ZFSアレイを壊してオフサイトのディスクを「回転」させる道を進んではいけません。ご覧のように、再構築時間は長く、再同期プロセスはデータセットの使用サイズを読み取り/検証します。

能力があれば、スナップショットとリモートシステムへのデータの送信は、クリーンで邪魔にならないアプローチです。専用の単一ディスクプール、それへのコピー、およびzpool export / import ...のプロセスを実行できると思いますが、あまりエレガントではありません。

さらなる実験の後、私は公正な解決策を見つけましたが、それは大きなトレードオフを伴います。offline削除されたが切り離されていないディスクは、後でインクリメンタル再同期操作のみでオンラインに戻すことができます（「デバイスがオンラインになると、プールに書き込まれたすべてのデータが新しく利用可能なデバイスと再同期されます。」）。私のテストでは、これにより3ディスクミラーの再同期時間が28時間から30分強に短縮され、約40GBのデータ差分が生じます。

トレードオフは、オフラインのディスクを含むすべてのプールに機能低下のフラグが付けられることです。少なくとも2つのオンラインディスク（ミラープール内）がまだある場合、これは事実上警告です。整合性と冗長性はそのまま残ります。

他の人が述べたように、この全体的なアプローチは理想からはほど遠いです-スナップショットをリモートプールに送信することははるかに適していますが、私の場合は実現可能ではありません。

要約すると、プールからディスクを削除し、後で完全な再同期化を必要とせずに追加する必要がある場合、私がお勧めするアプローチは次のとおりです。

• プール内のディスクをオフラインにします。 zpool offline pool disk
• ドライブをスピンダウンします（物理的にプルする場合）： hdparm -Y /dev/thedisk
• ドライブをオフラインにした状態でプールを機能低下状態のままにする
• ディスクをプールに戻すには： zpool online pool disk

また、これはまだテストされていないため、デルタ再同期処理が正確でない可能性があります。「ライブ」プールまたはオフラインディスク、あるいはその両方で問題が発生する可能性があります。それが起こった場合は更新しますが、今のところ、このアプローチを実験します。

2015年10月15日更新：今日、zpool splitコマンドを発見しました。このコマンドは、新しいプール（新しい名前）を既存のプールから分割します。 同じシステムに両方のプールが存在する（そして個別にスクラブされる）ことができるsplitためoffline、およびよりもはるかにクリーンdetachです。新しいプールはexport[ed]、システムから取り外す前に、クリーンに（適切に）することもできます。

（私の元の投稿は以下の通りです。）

警告！ このページのさまざまなコメントはzpool detach、ドライブで可能である（または可能である可能性がある）ことを意味し、ドライブを再接続して、ドライブに含まれるデータにアクセスします。

ただし、このスレッド（および私自身の実験） によるとzpool detach、切り離されたドライブから「プール情報」が削除されます。言い換えれば、a detachはドライブをすばやく再フォーマットするようなものです。後detachのデータの多くはまだドライブ上にあってもよいが、次のようになります事実上不可能ドライブを再マウントして使用可能なファイルシステムとしてデータを表示します。

その結果、detach破壊されたプールを回復できるdestroyと私は信じているので、より破壊的であるように見えzpool importます！

Aはdetachありませんumount、でもzpool export、でも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番目の（コピー）プールでのみ実行でき、ソースプールでは実行できません。