解決策 1:
LVM-HOWTO のスナップショットのセクションを見てみませんか?
LVM スナップショットは、基本的な「コピー オン ライト」スナップショット ソリューションです。スナップショットは、ファイルシステムの現在の状態への「ポインター」を提供し、スナップショット後に行われた変更を指定された領域に書き込むように LVM に要求するだけです。
LVM スナップショットは、別のボリュームではなく、スナップショットの対象となるボリュームをホストするボリューム グループ内で「ライブ」になります。 「...パーティションではなく、割り当てられていない空き領域がたくさんある」というあなたの声明は、スナップショットがスナップショットの対象となるボリュームグループの外で「生きている」というあなたの考えのように聞こえますが、それは正確ではありません。ボリューム グループはハードディスク パーティションに存在し、ボリュームはスナップショットの対象であり、そのボリューム グループでライブで撮影したスナップショットです。
LVM スナップショットが使用される通常の方法は、長期保存用ではなく、バックアップを取得できるようにファイルシステムの一貫した「全体像」を取得するためのものです。バックアップが完了すると、スナップショットは破棄されます。
LVM スナップショットを作成するときは、スナップショットがアクティブな間に加えられた変更を保持するための容量を指定します。スナップショット用に指定したスペースよりも多くの変更が加えられた場合、スナップショットは使用できなくなり、破棄する必要があります。 (a) スナップショットがいっぱいになって使用できなくなるため、(b) スナップショットがアクティブな間はシステムのパフォーマンスが影響を受け、動作が遅くなるため、スナップショットを放置したくありません。
編集:
Microsoft ボリューム シャドウ コピー サービスと LVM スナップショットが行うことは、それほど大きな違いはありません。 Microsoft のソリューションはもう少し包括的です (Microsoft の場合はよくあることですが、良くも悪くも、Microsoft のツールや製品は、1 つのことに集中するのではなく、かなり大きな問題を解決しようとすることがよくあります)。
VSS は、スナップショットとソフトウェア ベースのスナップショットをサポートするハードウェア デバイスのサポートを 1 つの API に統合する、より包括的なソリューションです。さらに、VSS には、スナップショット API を介してアプリケーションを静止できるようにする API がありますが、LVM スナップショットはスナップショットのみに関連しています。アプリケーションの静止はユーザーの問題です (データベースを「バックアップ」状態にするなど)。
解決策 2:
Evan が言ったように、LVM スナップショットはコピー オン ライト スナップショット ソリューションの一例です。それがどのように機能するかは、Evan が暗示しているものとは少し異なりますが、それほどではありません。
スナップショットのない LVM ボリュームがある場合、ボリュームへの書き込みは期待どおりに行われます。ブロックが変更され、それだけです。
スナップショットを作成するとすぐに、LVM はブロックのプールを作成します。このプールには、ボリュームの LVM メタデータの完全なコピーも含まれています。 i ノードの更新など、メイン ボリュームへの書き込みが発生すると、上書きされるブロックがこの新しいプールにコピーされ、新しいブロックがメイン ボリュームに書き込まれます。これが「コピーオンライト」です。このため、スナップショットが作成されてからメイン ボリュームの現在の状態までの間に変更されたデータが多いほど、そのスナップショット プールによって消費されるスペースが多くなります。
スナップショットをマウントすると、スナップショットが作成されたときに書き込まれたメタデータにより、ボリューム (またはより高いレベルのスナップショット) 内の変更されたブロックに対するスナップショット プール ブロックのマッピングが可能になります。このようにして、特定のブロックへのアクセスが発生すると、LVM はどのブロックへのアクセスかを認識します。そのボリュームのファイルシステムに関する限り、スナップショットはありません。
James は、このシステムの欠点の 1 つを指摘しました。同じボリュームの複数のスナップショットがある場合、メイン ボリュームのブロックに書き込むたびに、すべてのスナップショットで書き込みがトリガーされる可能性があります。これは、各スナップショットが変更されたブロックの独自のプールを維持するためです。また、長いスナップショット ツリーの場合、スナップショットにアクセスすると、サーバー上でかなりの計算が発生し、アクセスのためにどのブロックを提供する必要があるかを判断する必要があります。
スナップショットを破棄すると、LVM はスナップショット プールを削除し、必要に応じてスナップショット ツリーを更新します。ドロップされたスナップショットがスナップショット ツリーの一部である場合、一部のブロックが下位レベルのスナップショットにコピーされます。最下位のスナップショット (または唯一のスナップショット) である場合、プールは削除されるだけで、操作は非常に高速です。
一部のファイルシステムはファイルシステム内スナップショットを提供しますが、ZFS と BTRFS はよく知られているものの 2 つにすぎません。ファイルシステム自体が変更された/変更されていないマッピングを管理しますが、それらは同様に機能します。一貫性を保つためにスナップショット ファミリ全体を fsck できるため、これは間違いなくより良い方法です。これは、直接の LVM では実行できないことです。
解決策 3:
LVM スナップショットは非効率的です。スナップショットが多いほど、システムの動作が遅くなります。
私たちが使用しているのは xfs のみをサポートしており、xfs_freeze を使用してファイル システムへの新しいアクセスを停止し、ディスク上に安定したイメージを作成できます。
コピー オン ライトが使用されるため、ディスク領域が効率的に使用されます。
スナップショット用の予備スペースがある論理ボリュームにファイルシステムを作成しました。
これは FAQ の例です
解決策 4:
Linux と HP-UX のどちらを使用しているかは指定しません。 HP-UX では、論理ボリュームを作成し、それを別の論理ボリュームのスナップショットとしてマウントします。 Linux では、論理ボリュームをスナップショット ボリュームとして作成します。
HP-UX でスナップショットを削除するには、ボリュームをアンマウントします。 Linux では、lvremove を使用して論理ボリュームを削除します。
いずれにせよ、スナップショットに保存されるのは変更のみです。スナップショットが利用可能な期間が長ければ長いほど、より多くの変更が蓄積されます。適切なサイズまたはリリースを行わないと、スナップショットがいっぱいになる可能性があります。
スナップショット ボリュームのディスク アクセス速度は、通常のボリュームよりも遅くなります。それを考慮に入れる必要があります。