バックアップを送信するプールは、zfs send基本システムのバックアップ用に特別に設定されています。リモート位置にドライブミラーが必要ですか？それとも、次回呼び出されたときにzfsがエラーを修正するのに十分スマートですかzfs send？
明確にするには：自宅にzfsプールでミラーリングされた2台のドライブを持つメインサーバーがあります。それでは、zfsを含むOSを実行している外部サーバーに置き換えられないデータを送信したいと思います。
問題は、オフサイトの冗長性も必要かどうかです。
zfs scrub外部の場所でエラーが検出されたとします。zfs sendバグが修正されますか？
答え1
ミラーは必ずしも必要ではありませんが、そうすることでプールに保存されたデータの信頼性が向上します。
影響を受けたデータが重複しない場合、ZFSはエラーを回復しません。ディスク自体は不良ブロックを内部で交換して処理するため、プールを再送信すると問題が「修正」されます。しかし、私はこれにあまりにも多くのことをしないし、失敗し続けるディスクを交換しません。
不良セクタはディスク自体では検出されないため、読み取る必要があります。このzpool scrubコマンドは、zfs プールからエラーを検索するように設計されています。
答え2
これSolaris ZFSのベストプラクティスドキュメントこの質問に答えてください：
ZFS冗長性（RAIDZまたはミラーリング）なしで作成されたプールは、データの不一致のみを報告できます。データの不一致を修正することはできません。 ZFS冗長化なしで作成されたプールは、非冗長ZFS構成でディスクを交換または分離できないため、管理が難しくなります。
zfs send/recvデータを上書きする場合（正しいフラグを使用する場合）、これが心配なのかどうかはあなたのケースによって異なります。たとえば、5分ごとに新しいブロックを送信し、デフォルトプールが2分後にシャットダウンされると、バックアッププールが1週間、1ヶ月、またはそれ以上に1回だけ更新される場合よりも破損の可能性がはるかに低くなります。
ハードウェアの可用性も重要かもしれません。バックアップディスクが寿命を超えましたが（問題ありません。デフォルトプールはまだ残っています）、1日間交換できず、複数の予約済みバックアップが失敗した場合はどうなりますか？冗長性は、データの整合性だけでなくハードウェアレベルでも役立ちます。もちろん、作業を続ける他の2台のマシンがある場合は問題ありません。
特別なユースケース（スペースまたはポートの制限のために1つのディスクしか使用できず、プールサイズが最大ディスクサイズの半分未満）の場合は、copies=2バックアッププールを設定するオプションがあります。これにより、データがバックアッププールに内部的に複製され（200％のスペースが必要）、データの整合性が得られますが、ハードウェア障害が原因でバックアッププールが破壊される可能性があります。それにもかかわらず、長期のオフサイトバックアップストレージまたは単一のディスクしか使用できない小規模システムに役立ちます。既存のデータでは機能しないため、後で完全バックアップが必要です。
また、リンクガイドの警告：
ZFSトランスポートストリームがファイルまたはテープに保存され、ファイルが破損している場合、そのストリームは受信されず、すべてのデータを回復できません。
つまり、そうしない妥当な理由がない限り、このsendオプションを一緒に使用する必要がありますreceive。これは、アクティブなインポートプールのみが破損しているかどうかを確認できるためです。ストリームのみを保存する場合（たとえば、ターゲットプールが複数のストリームを同時に保持する場合）、zstreamdump整合性検証が推奨されます。