免責事項：zvolを使用したことがないので、zvolsが通常のファイルシステムまたはスナップショットとレプリケーションで異なるかどうかは言えません。私は彼らがそうであると思いますが、それについて私の言葉を受け入れません。
あなたの質問は実際には複数の質問です、私はそれらに別々に答えようとします：
プール全体をリモートロケーションに複製/ミラーリングする方法
タスクを2つの部分に分割する必要があります。最初に、レプリケーションスナップショットを台無しにしない限り、最初のレプリケーションを完了し、その後増分レプリケーションを実行する必要があります。増分レプリケーションを有効にするには、最後のレプリケーションスナップショットを保存する必要があります。それ以前のすべてを削除できます。以前のスナップショットを削除すると、zfs recv文句を言い、複製を中止します。この場合、最初からやり直す必要があるため、これを行わないようにしてください。
正しいオプションが必要な場合は、次のとおりです。
zfs send：
-R：指定されたプールまたはデータセットの下にすべてを送信します（常に必要な再帰的レプリケーションを含む-p）。また、受信すると、削除されたすべてのソーススナップショットが宛先で削除されます。-I：最後のレプリケーションスナップショットと現在のレプリケーションスナップショットの間のすべての中間スナップショットを含める（インクリメンタル送信でのみ必要）
zfs recv：
-F：ソースで削除された既存のデータセットの削除を含む、ターゲットプールの展開-d：ソースプールの名前を破棄し、宛先プール名に置き換えます（ファイルシステムパスの残りは保持され、必要に応じて作成されます）-u：宛先にファイルシステムをマウントしません
完全な例が必要な場合は、小さなスクリプトを次に示します。
#!/bin/sh
# Setup/variables:
# Each snapshot name must be unique, timestamp is a good choice.
# You can also use Solaris date, but I don't know the correct syntax.
snapshot_string=DO_NOT_DELETE_remote_replication_
timestamp=$(/usr/gnu/bin/date '+%Y%m%d%H%M%S')
source_pool=tank
destination_pool=tank
new_snap="$source_pool"@"$snapshot_string""$timestamp"
destination_host=remotehostname
# Initial send:
# Create first recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Initial replication via SSH.
zfs send -R "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Incremental sends:
# Get old snapshot name.
old_snap=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$source_pool"@"$snapshot_string" | tail --lines=1)
# Create new recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Incremental replication via SSH.
zfs send -R -I "$old_snap" "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Delete older snaps on the local source (grep -v inverts the selection)
delete_from=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$snapshot_string" | grep -v "$timestamp")
for snap in $delete_from; do
zfs destroy "$snap"
done
SSHよりも高速なものを使用する
IPSecまたはOpenVPNトンネルなど、十分に安全な接続があり、送信者と受信者の間にのみ存在する別個のVLANがある場合、ここで説明するようにSSHからmbufferなどの暗号化されていない代替手段に切り替えるか、暗号化なしでSSHを使用できます圧縮を無効にします。詳細については、こちらをご覧ください。SSHの再コンパイルに関するWebサイトもありましたが、残念ながらURLは覚えていません-見つかったら後で編集します。
非常に大きなデータセットと遅い接続の場合、ハードディスクを介した最初の送信にも役立ちます（暗号化されたディスクを使用してzpoolを保存し、宅配便、郵便、または直接の封印されたパッケージで送信します）。送信/受信の方法は重要ではないため、すべてをディスクにパイプし、プールをエクスポートし、ディスクを宛先に送信し、プールをインポートしてから、すべての増分送信をSSH経由で送信できます。
乱れたスナップショットの問題
前述のように、レプリケーションスナップショットを削除/変更すると、エラーメッセージが表示されます
cannot send 'pool/fs@name': not an earlier snapshot from the same fs
これは、コマンドが間違っていたか、スナップショットを削除して最初からやり直す必要がある一貫性のない状態にあることを意味します。
これにはいくつかの負の意味があります。
- 新しいレプリケーションスナップショットが正常に転送されるまで、レプリケーションスナップショットを削除することはできません。これらのレプリケーションスナップショットには他のすべての（古い）スナップショットの状態が含まれるため、削除されたファイルとスナップショットの空き領域は、レプリケーションが終了した場合にのみ回収されます。これにより、プール上の一時的または永続的なスペースの問題が発生する可能性がありますが、これは完全なレプリケーション手順を再起動または完了することによってのみ修正できます。
- 追加のスナップショットが多数あるため、listコマンドの速度が低下します（これは修正されたOracle Solaris 11を除く）。
- スクリプト自体を除き、スナップショットを（偶発的な）削除から保護する必要がある場合があります。
これらの問題の可能な解決策が存在しますが、私は自分で試していません。zfs bookmarkこのタスク専用に作成されたOpenSolaris / illumosの新機能を使用できます。これにより、スナップショット管理が不要になります。唯一の欠点は、現時点では、再帰的にではなく、単一のデータセットに対してのみ機能することです。すべての古いデータセットと新しいデータセットのリストを保存してから、それらをループし、ブックマーク、送信、受信してからリスト（または必要に応じて小さなデータベース）を更新する必要があります。
ブックマークのルートを試してみたら、それがどのように機能するか聞いてみたいと思います！
zfs send -R ...か？を介して出力をパイプした場合ssh、エスケープ文字を無効にしましたzfs send -R ... | ssh -e none ...か？