btrfs sendテラバイト規模のデータを転送するために使用できますが、receiveこれらのコマンドは有用な進行出力を生成しません（使用されている場合でも-v）。成功を確認するには？
たとえば、という名前の新しいサブボリュームを作成する場合は、source1GBのランダムデータを書き込んで転送できるように、読み取り専用に設定します。
# btrfs subvolume create source
# head -c 1G < /dev/urandom > source/data
# btrfs property set source ro true
btrfs sendその後、新しいサブボリュームのコピーを使用して作成しますが、receive完了する前にプロセスを中止します。
# mkdir destination
# btrfs send source | btrfs receive destination
At subvol source
At subvol source
^C
btrfs subvolume list問題がないことを示します。
# btrfs subvolume list .
ID 1216 gen 370739 top level 5 path source
ID 1219 gen 371244 top level 5 path destination/source
新しいサブボリュームは正常に移動できますが、そのデータは明らかに破損しています。
# exa -lT
- ├── destination
- │ └── source
251M │ └── random_data
- └── source
1.1G └── random_data
btrfs subvolume show destination/sourceサブボリュームが不完全であるという警告は表示されません。これはsがsと等しくないことを示し、destination/source実行が完了した場合にのみsがsに設定されているようです。UUIDsourcedestination/sourceReceived UUIDsourceUUIDbtrfs receive
Received UUID作成されたサブボリュームが、btrfs receive別のファイルシステム上の対応するUUIDを持つサブボリュームの変更されていない完全コピーであることは保証されますか？
この部分man btrfs-senddestination/sourceそうしないことをお勧めします。上記の例では、将来のスナップショットの親スナップショットを使用すると、損傷を検出してsource回復できない可能性があることを示唆しているようです。しかし、このアドバイスの目的send -cとこのアドバイスがsend -p。
増分モード（オプション
-pおよび-c）では、送信者と受信者の両方が使用できる以前に送信されたスナップショットを使用して、送信されたスナップショットを他のファイルシステムで再構成するために送信する必要がある情報の量を減らすことができます。
-p <parent>与えられたら、このオプションを省略できます。-c <clone-src>この場合、btrfs sendはレプリケーションソースから適切な親エントリを決定します。これらのスナップショットが両方（送信者と受信者）の両方でまったく同じ状態にあることを保証しない限り、複製ソースを指定することはできません。
私が知る限り、snap-sync、buttersinkその他の同様のツールは、出力をbtrfs send一連のファイルにリダイレクトし、信頼できる方法（rsync単純パイプではなく）を使用して送信することによってこの問題を解決します。ディストリビューションに含まれていないサードパーティ製ソフトウェアに依存せずに自己増分バックアップソリューションを開発する場合、これは正しいアプローチですか？
ベストアンサー1
Received UUID重要な要約：このフラグが設定されていると、readonly不注意や悪意が介入されない限り、問題が発生する可能性はありません。
@timakroがすでに答えで述べたように、Received UUIDこの転送が完了するまで設定されません。フラグも同じですreadonly。これは、ストリーム内のすべてのコマンドがチェックサム処理されるという事実と組み合わせて（私が知っている限り、送信されたメタデータにもチェックサムが含まれている）、受信側で破損したスナップショットで終わる可能性が低くなりますreadonly。Received UUID。これらのいずれかが設定されていない場合、btrfsは将来の参照のためにそのスナップショットの使用を拒否しますbtrfs receive。
特別に作成されたストリームを受信した場合、または一部のプロセスまたはユーザーが受信したスナップショットを受信している間にその内容を変更すると、意図的な損傷が発生する可能性があります。btrfs-receiveマンページから：
間違い
btrfs receive が正常に完了すると、サブボリュームを読み取り専用に設定します。ただし、受信プロセス中に、受信パスのファイルまたはディレクトリへの書き込み権限を持つユーザーは、ファイルを追加、削除、または変更できます。この場合、結果の読み取り専用サブボリュームは、トランスポートサブボリュームの正確なコピーではありません。
正確なコピーを作成することが目的の場合は、受信操作が完了し、サブボリュームが読み取り専用に設定されるまで、受信パスをユーザーアクセスから保護する必要があります。
さらに、現在の受信は、デルタトランスポートストリームが実際に意味があるかどうかを確認する操作を正しく実行していないため、特別に作成されたトランスポートストリームは、同じファイルシステム上の任意のファイルへの参照リンクを含むサブボリュームを作成できます。したがって、ユーザーは信頼できないソースからのトランスポートストリームにbtrfs受信を使用しないでください。信頼できないネットワークを介して信頼できるストリームを送信するときに信頼できるストリームを保護することをお勧めします。
readonlyまた、サブボリュームのフラグを無効にし、内容を変更してから再度有効にできることにも注意する価値があります。どちらにしても、すべての保証はなくなります。
出力をファイルにパイプしてファイルを転送するいいえ上記の保護のいずれかを提供してください。個人的にのbtrfs send出力をssh。ストリームをファイルに途中で保存すると、信頼できない接続によって中断された転送を再開できるという利点があります。いいえデータの整合性の形式では、いかなる保証も提供されません。
受信したスナップショットが送信されたスナップショットと一致することを確認するための良い（完璧ではありませんが）方法は、を使用することですrsync -avcn --del path/to/sent/snapshot/ user@remote:path/to/received/snapshot/。