snapper やsnapperなどを使用して時間ベースのスナップショットを取得できるように、データドライブでbtrfsを使用することを検討しています。これで私のデータの古いバージョンを閲覧できると思います。ドライブの障害によりデータとスナップショットが消去されるため、これは現在のオフサイトバックアップに追加されます。
私の理解では、btrfsスナップショットは多くのスペース(変更されたメタデータとブロック、およびおそらくオーバーヘッド)を占有しないので、スペースは制約ではないようです。
100万個のスナップショットがある場合(たとえば、2分間、1分ごとのスナップショット)、データ、変更されたデータ、およびメタデータ用に十分なディスク領域があるとすると、大混乱を引き起こしますか?
スナップショットの数に実際的な制限がある場合、それはファイルの数やファイルのサイズ、あるいはその両方に依存しますか?
技術的にはスナップショットの数に制限はありませんが、私は BTRFSメーリングリスト に尋ねました:
(実用的な)答えは、ある程度btrfsの使い方に依存します。
スナップショットが多すぎるためにBtrfsにはスケーリングの問題があり(実際には、reflinksスナップショットが使用し、reflinksを使用した重複排除が同じスケーリングの問題を引き起こす可能性があります)、スナップショットのサブボリュームごとに1桁から2桁のスナップショットのスナップショットが強く推奨されています。
ただし、スケーリングの問題は主にbtrfsメンテナンスコマンド自体、バランス、チェック、サブボリュームの削除に影響します。数百万のスナップショットは、たとえば効果的に機能しなくなります(作業の種類は異なりますが、数か月かかる場合があります)が、断片化が問題になる程度を除いて、ファイルの読み取りや保存などの通常のファイルシステム操作は影響を受けません( btrfsなどの牛のファイルシステムは、デフラグなどの手順を実行して削減しない限り、断片化が指摘されています)。
Time Machine/Snapperのようなアーカイブバックアップとしてスナップショットを使用することは良い考えではないようです。
ほぼArch Linux
でbtrfs
ファイルシステムを2
とともに使用している人として、私は安全に、スナップショットの数に実際的な制限はないと思われます。簡単に到達。ただし、いくつかの注意点があります。 btrfs
ファイルシステムは断片化を引き起こす可能性があります。したがって、btrfs
に組み込まれているオンラインでの最適化機能を使用することをお勧めします。さらに、btrfs
の圧縮機能をうまく利用できます。これらの対策は、かなりまともなコンピューターで大量のスナップショットを作成することから賢明に発生する可能性があるほとんどのパフォーマンスの問題に対処する必要があります。
ご存知かもしれませんが、btrfs
はサブボリュームをファイルシステムとして扱うため、スナップショットの数は確かに制限されています。つまり、ファイルのサイズによって制限されます。 btrfs
wikiによると、到達可能な最大ファイルサイズは2^64 byte == 16 EiB
[1] 。
これらの制限は別として、btrfs
ファイルシステムの空き容量を確認するのは難しい場合があります。 btrfs
ファイルシステム上のスペース実際に残っているスペースの量を簡単に追跡できます。このシナリオを防ぐ1つの可能な方法は、クォータの使用です。これにより、ユーザー(またはユーザーが1人の場合はそのユーザー)が特定の容量のみを使用できるようになります。この概念は、非常に上手く議論されます here および here 。
最後に重要な警告ですが、私はbtrfs
ファイルシステムの専門家ではありません。これらについては、少し前に同じ質問があった場合にのみお読みください。さらに、btrfs
は「動きの速いターゲット」であるという問題が常にあります(Arch Linux
wikiページからいい言葉が盗まれていると思います)。
あなたは2の合計を持つことができます64 スナップショットとサブボリューム。
btrfs
design wiki page は(empahsis mine)と述べています:
サブボリュームは基本的に、ファイルとディレクトリを保持する名前付きのbtreeです。ツリールートのツリー内にiノードがあり、ルート以外の所有者とグループを持つことができます。サブボリュームにはブロックの割り当てを与えることができ、この割り当てに達すると、新しい書き込みは許可されません。サブボリューム内のすべてのブロックとファイルエクステントは、スナップショットを作成できるように参照カウントされます。 最大264 サブボリュームはFSに作成できます。
スナップショットはサブボリュームと同じですが、ルートブロックは最初に別のサブボリュームと共有されます。スナップショットが作成されると、ルートブロックの参照カウントが増加し、コピーオンライトトランザクションシステムにより、スナップショットまたはソースサブボリュームのいずれかで行われた変更がそのルートに対してプライベートになります。スナップショットは書き込み可能であり、何度でもスナップショットを再作成できます。読み取り専用のスナップショットが必要な場合は、作成時にブロッククォータが1に設定されます。