データドライブでbtrfsを使用して、snapperまたはsnapperのようなものを使用して時間ベースのスナップショットを取得できるようにすることを検討しています。これにより、古いバージョンのデータを閲覧できるようになると思います。ドライブに障害が発生するとデータとスナップショットが消去されるため、これは現在のオフサイトバックアップに追加されます。
私の理解では、btrfsスナップショットは多くのスペースを占有しないため（メタデータと変更されたブロック、さらにオーバーヘッドが発生する可能性があります）、スペースは制約ではないようです。
100万のスナップショット（たとえば、2年間、毎分スナップショット）がある場合、データ、変更されたデータ、およびメタデータ用の十分なディスク容量があると仮定すると、大混乱を引き起こしますか？
スナップショットの数に実際的な制限がある場合、それはファイルの数やファイルのサイズに依存しますか？
承認された回答：
btrfsを使用している人として Arch Linuxを使用したファイルシステム ほぼ2 何年もの間、簡単に到達できるスナップショットの数に実際的な制限はないように思われると言っても過言ではありません。ただし、いくつかの注意点があります。 btrfs ファイルシステムは断片化につながる可能性があります。したがって、btrfsに組み込まれているオンラインデフラグ機能を使用することをお勧めします。 。さらに、btrfsを有効に活用できます。 の圧縮機能。これらの対策は、かなりまともなコンピューターで大量のスナップショットを作成することで賢明に発生する可能性のあるほとんどのパフォーマンスの問題に対処する必要があります。
ご存知かもしれませんが、btrfs サブボリュームをファイルシステムとして扱うため、スナップショットの数は実際に制限されます。つまり、ファイルのサイズによって制限されます。 btrfsによると wikiに到達できる最大ファイルサイズは2^64 byte == 16 EiB 。
これらの制限とは別に、btrfsの空き領域を確認するため、すぐに認識せずに領域が不足すると、常に問題が発生する可能性があります。 ファイルシステムは、トリッキーな場合があります。つまり、btrfsの空き領域を測定するさまざまな方法を区別できない場合があります。 ファイルシステムでは、実際に残っているスペースの量を簡単に追跡できます。このシナリオを防ぐための1つの可能な方法は、クォータを使用することです。これにより、ユーザー（または1人だけの場合はユーザー）が特定のスペースしか使用できないようになります。この概念は、こことここでも非常にうまく議論されています。
最後になりましたが、警告：私はbtrfsの専門家ではありません ファイルシステムと私がしばらく前に同じ質問をしたときだけこれらのことについて読んだ。さらに、btrfsという問題は常にあります。 は「動きの速いターゲット」です（Arch Linuxから盗まれた素敵な言葉遣い wikiページだと思います。）そうすると状況が変わるかもしれません。