KVM ストレージ用に LVM を試したことはありませんが、Samba のシャドウ ボリューム機能には LVM を使用しました。1 つ言えることは、パフォーマンスが最悪だったことです。
スナップショットごとに、追加の書き込みが発生する必要があります。 1 つのベース スナップショット ボリュームと 4 つのスナップショットがある場合、ベース ボリュームに書き込むと、ドライブへの書き込み量は 5 倍になります。
具体的な質問について:
- LVM は、スナップショットの実行中にファイル システムをフリーズします (書き込みの停止、キャッシュのフラッシュ、スナップショットの実行、書き込みの再開)
- 私が言ったように、とても遅いです
- はい、基本ボリュームが破損していると、すべてのスナップショットが使用できなくなります。さらに、スナップショット デルタに割り当てられたスペースが不足すると、スナップショットもホースされます
- はい、スナップショットを作成できます
残念ながら、私が知っているスナップショットでうまく機能するシステムは、NetApp WAFL、ZFS、および btrfs の 3 つだけです。システムが重要でない場合は、btrfs を試してみる価値があります。
これを行うことはまったく問題ありません。しないこと 必要なのは、スナップショットの親 (オリジナル、ソース、またはそれを呼びたいもの) を同時に使用することです。これは、IO の乗算が発生するためです (ヒューバートはこれについて正しかったです。ソースボリュームを常に使用しないことで簡単に防止できます)。
LVM に 1 つのマスター OS インストールがあり、それを 4 回スナップショットする場合、個々のスナップショット ボリュームに書き込むだけなので、IO のペナルティはあまりありません。もちろん無料ではありませんが、他のファイルシステムや仮想ディスクでの他の形式のスナップショットも無料ではありません。必ずどこかにコストがかかります。
Hubert のもう 1 つの正しい点は、スナップショットのサイズについて考える必要があるということです。スナップショット ボリュームが書き込みを継続できることを確認する必要があります。完全なスナップショット ボリュームは、物をひどく壊します。これを防ぐ確実な方法は、スナップショット ボリュームをソース ボリュームと同じサイズ (またはそれ以上) にすることです。ただし、この方法では使用するディスク容量が少なくなるという利点が失われます。
qemu イメージもスナップショット対応であることをご存知ですか?
シン プロビジョニング LVM は、ここ 2019 年に、このシナリオの主要なオプションと見なす必要があります。
Thin LV のパフォーマンスは良好であり、それらは個別のボリュームのように機能するため、スナップショットが作成されると、オリジナルのケアと整合性について心配する必要はありません (スナップショットに影響を与えずに破損、削除などを行うことができます)。
「スナップショットが実際のスペースをほとんど占有しない」という OP の懸念 スナップショットごとにモノリシックな方法でスペースを事前に割り当てる必要があるため、従来の LVM では十分ではありません。しかし、シン LV はスパース ファイルのように割り当てられ、実際にはほとんどスペースを占有しません。
シン プロビジョニングのトレードオフは、シンプール内の使用可能なスペースがいっぱいにならないように、ファイル システムと同じように監視する必要があることです。通常、Linux ディストリビューションには、これを監視し、警告を送信したり、シンプールがほぼ満杯の状態に達したときにアクションを実行したりするデーモンがあります。