btrfs：ボリュームを外部ファイルにイメージングする
最近、btrfsルートパーティションを使用してシステムを構築しました。私の場合、ext4と比較してbtrfsを採用する最も説得力のある理由は、待ち時間がほぼゼロのライブコピーオンライトスナップショットでした。 ext4と比較して、システム全体のバックアップでシステムの停止、ライブディストリビューションからのマウント、リムーバブルメディアでのpartcloneイメージの構築が必要な場合、スナップショットの約束はスナップショットをキャプチャできることです。システムが稼働している間、バックアップメディア上で。
驚いたことに、スナップショット全体を外部メディア上の単一のファイルにキャプチャするツールは存在しません。そのため、システムがそのファイルから復元された場合、すべてのアプリケーションはクラッシュ前と同じファイルシステムのビューを持ちます（ただし、他のスナップショットまたはサブボリュームが欠落しています）。
ドキュメントでは、rsyncなどのツールを使用してディレクトリツリーをミラーリングするか、btrfs-send/btrfs-receiveを使用して別のシステムの増分変更をキャプチャすることを提案しています。最初のケースでは、ファイルシステムをイメージングするのではなく、ファイルツリーをミラーリングするだけでファイルツリー内のすべてのメタデータを正確に再作成することはほぼ不可能であり、復元が非常にスムーズになるという楽観的な見方はほとんどありません。権限、タイムスタンプ、隠しファイルなど、一部のメタデータが適切にキャプチャされていないことに常に気付きます。異なるタイプのファイルシステム間で転送が発生すると、問題はさらに複雑になります。もう1つの提案は、別のbtrfsファイルシステムが使用可能であることを前提としていますが、常にそうであるとは限りません。
パートクローンファイルと同様に、選択したサブボリュームのみを表すボリュームレベルのイメージを保存または復元するための提案はありますか？
btrfs sendとbtrfs receiveは、まさに必要なツールです。
ファイルシステムをイメージングするのではなく、ファイルツリーをミラーリングするだけでファイルツリー内のすべてのメタデータを正確に再作成することはほぼ不可能であり、復元が非常にスムーズになるという楽観的な見方はほとんどありません。権限、タイムスタンプ、隠しファイルなど、一部のメタデータが適切にキャプチャされていないことに常に気付きます。
ツールを試しましたか？ btrfsでそのような問題は発生していません。 btrfs sendおよびbtrfs receiveはファイルでは機能せず、サブボリューム全体で機能し、すべてのBtrfsメタデータにアクセスできますネイティブ。
異なるタイプのファイルシステム間で転送が発生すると、問題はさらに複雑になります。もう1つの提案は、別のBtrfsファイルシステムが使用可能であることを前提としていますが、常にそうであるとは限りません。
replicateサブボリュームが必要な場合にのみ、別のBtrfsファイルシステムが必要になります。これは多くの場合望ましいので、マウントしてファイルにアクセスできます。また、サブボリュームを段階的にバックアップする場合は、これは避けられません。次のスナップショットを段階的に送信するには、両方の場所に正確な前のスナップショットが必要です。
ただし、フルダンプを使用すると、スタンドアロンストリームが取得されます。これは、まさにイメージです（ただし、btrfs restoreしない限り、閲覧可能なバックアップではありません）。他のストリームと同じように操作します。
btrfs send /source/subvolume >/another/filesystem/subvolume-image # just a file
# (or you can gzip it and/or send with nc on the fly, whatever)
# then later
</another/filesystem/subvolume-image btrfs receive /some/btrfs/directory
ここで、/some/btrfs/directoryは/sourceと同じBtrfsファイルシステムに属している可能性があります。