データドライブでbtrfsを使用して使用できるように検討しています。ドミ、または時間ベースのスナップショットを撮ることができるスナッパーのようなものです。私はこれが以前のバージョンのデータをナビゲートできるようになると信じています。ドライブエラーが原因でデータとスナップショットが削除されるため、これは現在のオフサイトバックアップに追加されます。
私が理解したところによると、btrfsスナップショットは多くのスペース（メタデータと変更されたブロック、そしておそらく少しのオーバーヘッド）を占めないので、スペースが制限されないようです。
百万のスナップショット（たとえば、2年間に1分に1つ）がある場合、データ、変更されたデータ、およびメタデータを格納するのに十分なディスク容量があると仮定すると、これは大きな混乱を招く可能性がありますか？
スナップショット数に実際の制限がある場合は、ファイル数やファイルサイズによって異なりますか？
ベストアンサー1
ここ数年でbtrfsファイルシステムを使ってきた人として、簡単に得られるスナップショットの数には実質的な制限がないようだと安全に言えます。ただし、いくつかの注意事項があります。ファイルシステムは断片化できます。したがって、組み込みのオンラインデフラグ機能を使用することをお勧めします。また、圧縮機能を最大限に活用できます。これらのアクションは、合理的にまともなシステムで多数のスナップショットを作成するときに明らかになる可能性があるほとんどのパフォーマンス問題を解決する必要があります。Arch Linux2btrfsbtrfsbtrfs
ご存知のように、btrfsサブボリュームはファイルシステムと見なされるため、スナップショットの数はファイルサイズによって実際に制限されます。 Wikiによると、 btrfs達成できる最大ファイルサイズは次のとおりです。2^64 byte == 16 EiB[1]。
これらの制限に加えて、ファイルシステムの空き容量を確認することは時々難しいかもしれません。つまり、空き領域を測定するさまざまな方法をbtrfs区別できる方法はありません。btrfsファイルシステムから。実際の残りのスペースを簡単に追跡できます。これを防ぐ 1 つの可能な方法は、クォータを使用することです。これにより、ユーザー（またはユーザーが1人だけのユーザー）が特定のスペースのみを使用できるようになります。この概念は非常に巧妙に議論されています。ここそしてここ。
最後ですが重要な警告：私はbtrfsファイルシステムの専門家ではなく、しばらく前に同じ問題に直面したときにこの記事を読んでいました。また、いつも「素早く動く目標」（btrfsウィキページから盗んだ素敵な表現だと思います。）問題があるので状況が変わることがあります。Arch Linux