最初の免責事項として、私はスナップショットにインセプションスタイルのスナップショットを含めたくありません。
たとえば、@にマウントし/てから@_snapshotsマウントした場合、それはサブボリュームであるため、スナップ/.snapshotsショット/.snapshotsには含まれませんが、/まだ表示されます/。これはいいですね。
しかし、例えば、@home_fsinatraどこにインストールされていますか/home/fsinatra？このサブボリュームのスナップショットはどこに配置する必要がありますか？@home_fsinatra_snapshots？/home/fsinatra/.snapshotsまたはどこかにある専用のスナップショットサブボリューム/.snapshots/...（これを達成する方法はわかりませんが）。
私はZFS固有のネストされたデータセットとスナップショットについて非常によく知っており、最初からBtrfsを使用しましたが、これまではスナップショットに触れるのを避けました。これは、実際には論理的にネストされたサブボリュームとスナップショットを使用するZFSの現在のシステムなど、Btrfsに新しいシステムドライブをマウントすることです（単純化のために、おそらく文字通りの単純な構成を取って「ネストされたセット」を渡しますがfstab） 。スナップショットは手動で作成することも、Snapperを介して自動的に作成することもできます。
私はBtrfs以外の特定のアイデアや要件にとらわれず、いくつかのアイテム（システムや個人ユーザーのホームページなど）のスナップショットを撮りますが、他のアイテム（さまざまなtmpとキャッシュディレクトリ、/ opt、/ var、dockerなど）のスナップショットは撮りません。 .) スナップショットを撮ります。私のサブボリュームも同じです。必要正直言って、私はそれが時代の精神に基づいて最も簡単なものだと思いました。
（これはDebian Bookworm BTW、SSDのamd64で動作します。）
答え1
これは単に人気のないトピックや答えが必要な質問ではないようですが、このトピックについて地球上には間違った情報が多かったり、少なくともこれについての理解が不足して12人がそれに多くの関心を持っています。 、そしてインターネット上で関連記事を書きました。
より関連性が高いのは、一般的な概念がファイルシステムユーザーツールの設計決定として不必要に複雑に見えることです。
私はもともと私自身の質問に答え、元の質問で提起された主張が実際に「ベスト」（唯一ではないが）アプローチである可能性がある理由を説明しました。具体的には：
しかし、例えば、
@home_fsinatraどこにインストールされていますか/home/fsinatra？このサブボリュームのスナップショットはどこに配置する必要がありますか？名前付き専用スナップショットサブボリュームから@home_fsinatra_snapshots[手動インストール]は/home/fsinatra/.snapshots？
しかし、それが唯一の方法ではありません。実際、このアプローチの欠点はすぐに明らかになります。たとえば、ホームディレクトリのスナップショットを頻繁にまたは自動的に（または実際にはすべて）撮影すると、ホームフォルダの下（特にそのフォルダセンター）にジャンクダミーがすばやく作成されることがあります。蓄積し、~/.snapshotsさまざまなユーティリティを損傷します。そのうちのいくつかは実際に避けるのが難しいか不可能です。もちろん、多くのユーティリティ（rsyncやバックアッププログラムなど）と他のユーティリティの特定のフラグを使用してそれらを除外できますが、他のユーティリティは除外できません。たとえば、単にシンボリックリンクとしてのみ表示されるわけではありません。
ZFSはデフォルトで非表示の仮想フォルダを使用して、この問題を優れた方法で解決します。 （ただポイントとして隠されているのではなく、ディレクトリリストにまったく表示されないため、特に名前を付けない限りアクセスできないという意味です。）
ZFSは、上記のアイデアと非常によく似たサブボリュームの下の「サブボリューム」（データセットまたはファイルシステムとも呼ばれる）のスナップショットを提供します。ただし、デフォルトではリテラル文字列を介して手動で繰り返さないと検索できません。ユーティリティやプログラムは、何らかの理由で正確な名前付きフォルダを明示的にテストするようにプログラムされていない限り、ファイルシステムを探索/スキャンして誤って検出されません。
ただし、Btrfsはこれを実行しないため（公平に言うと「標準」ではありません）、この「スナップショットの下のボリューム」は一般ユーザーにとってあまりにも多くの欠点を持つと予想されます。ただし、独自のサブボリュームなので、「スナップショットの起動」の問題を回避できます。ただし、これは、ユーザーが特に要求しない限り、ほとんどのツールがすでに検出して回避するのに非常に熟練した、より軽量なシンボリックリンクを使用して行うことができます。
だから私の新しいアプローチは、@と@home（そして他の）と兄弟であるスナップショットボリュームを使うことであり、すべてのスナップショットはそのボリュームの下にあります。私のデフォルトのBtrfsボリュームは次のとおりです。
@/ -> /
@home~fsinatra/ -> /home/fsinatra/
@snapshots/ -> /.snapshots/
@snapshots/@/ -> /.snapshots/@/
@snapshots/@home~fsinatra/ -> /.snapshots/@home~fsinatra/
@snapshotsの下の最初のレベルのオブジェクトは、ネストされたサブボリュームではなく、一般的なファイルシステムフォルダです。つまり、forは@snapshots/@/サブ@snapshotsボリュームですが、@その下には通常のフォルダがあります。 （この質問を投稿したときにこれが可能かどうかわかりませんでしたが、作業が簡単になりました@。/）/.snapshots/@/
各サブボリュームには、同じ名前の専用フォルダがあります@snapshots/。 （もちろんすべて手動で設定されます。）
君には理由がない持つミラースナップショットの下にサブボリューム名と同じフラットレイアウトがあります。代わりに、インストールされた階層を模倣することができます。しかし、スナップショットフォルダと何百、何千もの拡張可能な階層フォルダを混在させることは奇妙で管理するのが難しいようです。たとえば、スナップショットを明確に定義する方が明確だと思います。ただルート（@）の下には、各サブボリュームに同じレベルの専用スナップショットフォルダがあります。
繰り返しますが、スナップショットフォルダを階層ファイルシステムに入れ子にするには、シンボリックリンクフォルダの名前を.snapshotsbackに指定します/.snapshots。シンボリックリンクを使用すると、重いインストールフォルダで発生する上記の問題のほとんどを回避できます。
ミラーの下のサブボリューム名1：1も意味があります/.snapshot。その後、スナップショット名をYYYMMDD-HHMMSSとして指定できます。これはコンテキストに完全に一致します。
どの戦略を採用しても、知っておくべき大きな注意事項があります。
サブボリュームの真の平面レイアウトが必要な場合（手動でネストしたかどうかにかかわらずfstab）：
マウントされたファイルシステムにサブボリュームを作成しないでください。。
これにより、すべての新しいボリュームが実際に@.（またはにインストールされているサブボリューム名/）にネストされます。
代わりにすべきことは、デフォルトのBtrfsパーティション自体（指定されたサブボリュームなし）を安全な場所にマウントすることです。 （例えば、.）私は/mnt/btrfs-root一時的に、たぶん永久にこれをやっているだけです。これにより、他の最上位サブボリュームのみをfstab表示できる最上位レベルに簡単にアクセスできます。したがって、スナップショットおよび/またはユーザーのホームディレクトリ用の別のフラットサブボリュームを作成するときに、相対的でない別のサブボリュームを作成します。これにより、サブボリューム以外のサブボリューム（「ルート」サブボリュームを含む）になります。@@home/mnt/btrfs-root//
-o subvol=@/@snapshots（そうでなければinで指定する必要があります。fstabそうでなければマウントされません。には存在しません。@snapshotsそれが私をこの捨てられたウサギの洞窟に導きました。）
この概念を理解したら、それははっきりと見えるかもしれませんし、読者の皆さんにはいつもはっきりしていました。しかし、私が知っている限り、インターネット全体でそれについて書いた人はおそらくたった一人です。おかげで、多くの[追加]頭痛がある場合、オーディンは死後の世界でその人の魂を祝福することを願っています。
これが今後10年間で3人以上の人々に返信するのに役立つことを願っています。
私と他の人を混乱させる別のトリックがあります：DebianテストでCalamaresがBtrfsにインストールされている場合、Ubuntuは常にエントリの名前を別々に指定しますfstab（/@スラッシュ/@homeなし@）@home。私はスラッシュを使用または使用せずに実行してテストしましたが、私の場合はどちらも機能しました。私は先行スラッシュがより正確だと思います。それ以外のmount場合仮説これは、インストール中に指定されたボリュームのルートディレクトリに相対的です。