これはLVMスナップショットのしくみですか？
LVMスナップショットがファイルサーバーに実装できるように、LVMスナップショットがどのように機能するかを理解しようとしていますが、基本のバックアップシステムに使用する方法ではなく、動作を説明するものをGoogleで見つけるのが困難です。
私が読んだことから、私はそれが次のように機能すると思います：
- プライマリパーティションを備えたLVMがあり、パーティションにないたくさんの未割り当ての空き領域がある
- 次に、スナップショットを取り、それを新しい論理ボリュームにマウントします。スナップショットには変更があるはずなので、この最初のスナップショットは完全なコピーになりますよね？
- 次に、次の日、別のスナップショットを作成し（このスナップショットのパーティションサイズはそれほど大きくなくてもかまいません）、マウントします。
- どういうわけかLVMはスナップショットを追跡し、変更されていないビットをプライマリボリュームに保存しません。
- 次に、十分なスナップショットがあると判断し、最初のスナップショットを削除します。これがどのように機能するか、それが次のスナップショットにどのように影響するかはわかりません。
誰かが私が間違っているところを修正してくれますか？せいぜい、Googleでは何も見つかりません。
vgdiplay
obu1：/ home/jail/home/qps/backup/D＃vgdisplay ---ボリュームグループ--- VG名fileserverLVM システムID 形式lvm2 メタデータ領域1 メタデータシーケンス番号3 VGアクセス読み取り/書き込み VGステータスサイズ変更可能 MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VGサイズ931.51 GB PEサイズ4.00 MB 合計PE 238467 Alloc PE /サイズ238336/931.00 GB 無料PE /サイズ131/524.00 MB VG UUID qSGaG1-SQYO -D2bm-ohDf-d4eG-oGCY-4jOegU
LVM-HOWTOのスナップショットセクション を見てみませんか？
LVMスナップショットは、基本的な「コピーオンライト」スナップショットソリューションです。スナップショットは実際には、LVMにファイルシステムの現在の状態への「ポインター」を提供し、スナップショットの後に行われた変更を指定された領域に書き込むように要求することに他なりません。
LVMスナップショットは、別のボリュームではなく、スナップショットの対象となるボリュームをホストするボリュームグループ内で「ライブ」です。 「...パーティションではなく、未割り当ての空き領域がたくさんあります」という記述では、スナップショットは、スナップショットの対象となるボリュームグループの外部で「ライブ」であると考えられているように思われますが、正確ではありません。ボリュームグループはハードディスクパーティションに存在し、スナップショットの対象となるボリュームと、そのボリュームグループでライブで取得したすべてのスナップショット。
LVMスナップショットが使用される通常の方法は、長期間のストレージではなく、バックアップを取得できるようにファイルシステムの一貫した「画像」を取得するためのものです。バックアップが完了すると、スナップショットは破棄されます。
LVMスナップショットを作成するときは、スナップショットがアクティブな間に行われた変更を保持するための容量を指定します。スナップショット用に指定したスペースより多くの変更が行われた場合、使用できなくなり、破棄する必要があります。 （a）スナップショットがいっぱいになって使用できなくなるため、および（b）スナップショットがアクティブな間、システムのパフォーマンスに影響が及ぶため、スナップショットをそのままにしておくのは望ましくありません。
編集：
MicrosoftボリュームシャドウコピーサービスとLVMスナップショットの機能は、それほど大きな違いはありません。 Microsoftのソリューションは少し包括的です（通常、Microsoftの場合と同様に、ツールや製品は、1つのことに集中するのではなく、かなり大きな問題を解決しようとすることがよくあります）。
VSSは、スナップショットとソフトウェアベースのスナップショットをサポートするハードウェアデバイスのサポートを単一のAPIに統合する、より包括的なソリューションです。さらに、VSSにはAPIがあり、スナップショットAPIを介してアプリケーションを静止させることができます。一方、LVMスナップショットはスナップショットのみに関係しています。静止アプリケーションは問題です（データベースを「バックアップ」状態にするなど）。
LVMスナップショットは、Evanが言ったように、コピーオンライトスナップショットソリューションの例です。それがどのように機能するかは、エヴァンが暗示するものとは少し異なりますが、全体ではありません。
スナップショットのないLVMボリュームがある場合、ボリュームへの書き込みは期待どおりに行われます。ブロックが変更され、それだけです。
スナップショットを作成するとすぐに、LVMはブロックのプールを作成します。このプールには、ボリュームのLVMメタデータの完全なコピーも含まれています。 iノードの更新などの書き込みがメインボリュームに発生すると、上書きされるブロックがこの新しいプールにコピーされ、新しいブロックがメインボリュームに書き込まれます。これが「コピーオンライト」です。このため、スナップショットが作成されてからメインボリュームの現在の状態の間に変更されるデータが多いほど、そのスナップショットプールによって消費されるスペースが多くなります。
スナップショットをマウントすると、スナップショットの作成時に書き込まれたメタデータにより、ボリューム（またはより高いレベルのスナップショット）の変更されたブロックに対するスナップショットプールブロックのマッピングが可能になります。このように、特定のブロックへのアクセスがあった場合、LVMはどのブロックアクセスを認識します。そのボリューム上のファイルシステムに関する限り、スナップショットはありません。
ジェームズはこのシステムの欠点の一つを指摘しました。同じボリュームのスナップショットが複数ある場合、メインボリュームのブロックに書き込むたびに、すべてのスナップショットで書き込みがトリガーされる可能性があります。これは、各スナップショットが変更されたブロックの独自のプールを維持するためです。また、スナップショットツリーが長い場合、スナップショットにアクセスすると、サーバーでかなりの計算が行われ、アクセスのために提供する必要がある正確なブロックがわかります。
スナップショットを破棄すると、LVMはスナップショットプールを削除し、必要に応じてスナップショットツリーを更新します。ドロップされたスナップショットがスナップショットツリーの一部である場合、一部のブロックが下位レベルのスナップショットにコピーされます。それが最低のスナップショット（または唯一のスナップショット）である場合、プールはドロップされ、操作は非常に高速です。
一部のファイルシステムはファイルシステム内のスナップショットを提供しています。ZFSとBTRFSは、よく知られているものの2つにすぎません。ファイルシステム自体が変更済み/未変更のマッピングを管理しますが、これらは同様に機能します。一貫性を保つためにスナップショットファミリ全体をfsckできるため、これは間違いなく優れた方法です。これは、LVMをまっすぐに行うことではできません。
LVMスナップショットは非効率的です。スナップショットが多いほど、システムの処理速度は遅くなります。
私が使用するものとしてxfsのみをサポートし、xfs_freezeを使用してファイルシステムへの新しいアクセスを停止し、ディスク上に安定したイメージを作成できます。
書き込み時にコピー が使用されるため、ディスク領域が効率的に使用されます。
スナップショット用の予備スペースがある論理ボリュームにファイルシステムを作成しました。
LinuxとHP-UXのどちらを使用するかは指定しません。 HP-UXでは、論理ボリュームを作成し、それを別の論理ボリュームのスナップショットとしてマウントします。 Linuxでは、スナップショットボリュームとして論理ボリュームを作成します。
HP-UXでスナップショットを削除するには、ボリュームをアンマウントします。 Linuxでは、論理ボリュームを削除するためにlvremoveを使用して行われます。
いずれの場合も、スナップショットに保存されるのは変更のみです。スナップショットが利用可能なままである時間が長いほど、ストックされる変更が多くなります。適切なサイズまたはリリースでないと、スナップショットがいっぱいになる可能性があります。
スナップショットボリュームのディスクアクセスの速度は、通常のボリュームの場合よりも遅くなります。これを考慮に入れる必要があります。