バックアップ戦略としてのLVMスナップショット
Xen domUの定期的なLVMスナップショットは、バックアップ戦略としてどの程度実行可能でしょうか。長所、短所、問題点はありますか？
私にとっては、高速で頭脳のない復元のための完璧なソリューションのようです。破損した論理ボリュームに対して調査が行われ、domUが中断することなく正常に実行されます。
編集：
ここで、システム全体のバックアップを実行しています。
- domUディスクのlvmスナップショット
- サイズがスナップショットのサイズと等しい新しい論理ボリューム。
- dd if =/dev/snapshot of =/dev/new_lv
- lvremoveを使用したスナップショットの破棄
- kpartx/mount/lsによるオプションの検証
これを自動化する必要があります。
LVMスナップショットは、凍結状態のファイルシステムをキャプチャするためのものです。 それらはそれ自体でのバックアップを意図したものではありません。ただし、凍結されたイメージはバックアッププロセス中に変更できず、変更されないため、一貫性のあるバックアップイメージを取得するのに役立ちます。したがって、を直接使用して長期バックアップを作成することはありません。これらは、使用することにしたバックアッププロセスで非常に役立ちます。
スナップショットを実装するには、いくつかの手順があります。 1つ目は、新しい論理ボリュームを割り当てる必要があることです。このボリュームの目的は、ファイルシステムへのデルタ（変更）が記録される領域を提供することです。これにより、既存の読み取り/書き込みアクセスを中断することなく、元のボリュームを続行できます。これの欠点は、スナップショット領域のサイズが有限であることです。つまり、書き込みがビジーなシステムでは、すぐにいっぱいになる可能性があります。書き込みアクティビティが多いボリュームの場合、スナップショットのサイズを増やして、すべての変更を記録するのに十分なスペースを確保する必要があります。スナップショットがオーバーフローする（いっぱいになる）と、両方のスナップショットが停止し、使用不可としてマークされます。これが発生した場合は、スナップショットを解放して、元のボリュームをオンラインに戻すことができます。リリースが完了すると、ボリュームを読み取り/書き込みとして再マウントし、ボリューム上のファイルシステムを使用できるようになります。
次に発生することは、LVMが問題のボリュームの真の目的を「スワップ」することです。新しく割り当てられたスナップショットがファイルシステムへの変更を探す場所になると思うでしょう、結局のところ、すべての書き込みが行われる場所ですよね？いいえ、その逆です。ファイルシステムはLVMボリュームnamesにマウントされているため、nameをシステムの残りの部分の下はno-noになります（スナップショットがdifferentの名前を使用するため）。したがって、ここでのソリューションは単純です。元のボリューム名にアクセスすると、ボリュームのlive（読み取り/書き込み）バージョンを引き続き参照しますあなたはスナップショットをしました。作成するスナップショットボリュームは、バックアップするボリュームのfrozen（読み取り専用）バージョンを参照します。最初は少し混乱しますが、それは理にかなっています。
これはすべて2秒未満で行われます。システムの残りの部分は気付くことさえありません。もちろん、オーバーフローする前にスナップショットを解放しない限り...
ある時点で、スナップショットを解放して、占有しているスペースを解放する必要があります。リリースが完了すると、スナップショットボリュームはボリュームに解放され、元のボリュームが残ります。
これを長期的なバックアップ戦略として追求することはお勧めしません。障害が発生する可能性のある同じ物理ドライブ上でデータをホストしているため、障害が発生したドライブからファイルシステムを復元しても、バックアップはありません。
つまり、一言で言えば：
- スナップショットはバックアップの支援に適しています
- スナップショットは、それ自体はバックアップの形式ではありません
- スナップショットは永久に持続しない
- 完全なスナップショットは良いことではありません
- スナップショットはある時点で解放する必要があります
- LVMを賢く使用すれば、LVMはあなたの友達です。
LVMスナップショットは、サーバーをオフラインにすることなくサーバーをバックアップできる点で優れています。前述のように、LVMスナップショットはほぼ瞬時のコピーです。 LV自体を作成するのと同じように、lvcreateコマンドを使用してそれらを作成し、それに--snapshotオプションとVGではなく元のLV。例えば：
lvcreate -L <LV size> -s -n <snapshot name> /dev/<VG name>/<LV name>
これにより、指定されたLVのスナップショットが指定されたスナップショット名で作成されます。このスナップショットLVをマウントして使用すると、アクティブに使用されているファイルについて心配することなくバックアップを実行できます。これは、アクティブなデータベースサーバーをバックアップする場合に特に役立ちます。
スナップショットからのバックアップが完了したら、スナップショットを削除して、追加のI/Oオーバーヘッドや他のパフォーマンスの問題を軽減することができます。
lvremove /dev/<VG name>/<snapshot name>
LVMスナップショットは、データベースなどのシステムの信頼性の高いバックアップを作成する上で非常に貴重な場合がありますが、通常はファイルの競合を避けるためにバックアップにシャットダウンする必要があるため、迅速な復元としての長期的な運用には適していません。
いい考えではありません、IMO。
スナップショットはコピーオンライト方式で実装されているため、すべての書き込みを読み取りと2つの書き込みに変換します（更新先のブロックは、最初にメインボリュームから読み取られ、新しいデータが配置される前にスナップショットボリュームに格納されます）その場所）なので、VMで多くの書き込みが一般的である場合、パフォーマンスの低下が見られます。
また、IIRCは、スナップショットボリュームがいっぱいになると、単純に無作為に削除されます。これはバックアップ目的には適していません。したがって、これをバックアップ方法として使用する場合は、スナップショットの耐用期間中に発生するすべての変更を処理するのに十分な大きさのスナップショットボリュームを作成してください。もちろん、サイズの問題を認識して監視していて、パフォーマンスの問題が問題ではない場合は、提案している方法で、他のバックアッププロセスを有効に追加できます。
LVMスナップショットは、バックアッププロセス（スナップショットの取得、スナップショットの別の場所へのバックアップ）の一部として非常に役立ちます。 「実際の」ボリュームへの更新、後でスナップショットを削除するなど、他のものと同様ですが、それ自体のバックアップ機能としては意図されていません。
スナップショットを作成する前に、ディスク上のデータが一貫した状態であることを確認する必要があります。例えばmysqlは、データベースをダンプするかシャットダウンすることにより、強制的にディスクに書き込む必要があるメモリにキャッシュされたデータを持っている場合があります。詳細については、アプリケーションのマニュアルを参照してください。
スマートに見えるものの下にあるLVMは、実際にはデバイスマッパーのトリックにすぎません。 lvcreateでスナップショットを作成することは、いくつかのdmsetupのラッパーにすぎません。ラッパーは、1つの古いボリューム（元のlv）と新しいボリューム（copy-on-writeボリューム）から新しいデバイス（スナップショットボリューム）を作成します。それとともに、元のLVは-realに名前変更されます（以下を参照してください。これはdmsetup ls --tree出力です）。この実際のLVは、スナップショットボリュームと元のボリュームの両方にマッピングされるため、両方の場所で使用できます。コピーオンライトボリュームは、-real LVへのオーバーレイとして機能します。 -snap LVは、コピーオンライトボリュームと-realボリュームの組み合わせを示します。これは確かにパフォーマンスのオーバーヘッドを生み出します。
Volume00-snap (253:11)
|-Volume00-snap-cow (253:13)
| `- (104:2)
`-Volume00-LogVol01-real (253:12)
`- (104:2)
Volume00-LogVol01 (253:5)
`-Volume00-LogVol01-real (253:12)
`- (104:2)
スナップショットを削除すると、再び名前の変更とマッピングが行われます。その後、状況は再び次のようになります
Volume00-LogVol01 (253:5)
`- (104:2)
これは、物事をバックアップする良い方法です：これを考慮すると、これは（1）仮想マシンのRAMに役立ちません、（2）パフォーマンスのペナルティを作成し、（3）必要になりますスナップショットのイメージを別の場所に保存します。
VMware VCBは、LVMスナップショットではありませんが、スナップショットでも機能します。
スナップショットがパフォーマンスに影響を与えなかったとしても、理解しておく必要があります。スナップショットは、同じディスク上の別のフォルダーへのコピーにすぎません。
ディスクにブレーキがかかると、データとバックアップが失われます。 VG内の別のPEにスナップショット領域を割り当てても、スナップショット以降に変更されたデータのみが含まれます。
バックアップとは、最小要件として、少なくとも完全に別のドライブにコピーすることを意味します。
vMwareサーバーマシンとmysqlデータベースのスナップショットにこのような設定を使用します。これまでのところうまくいきます。いくつかの復元がありました-すべて問題なく。考慮すべきことの1つ-スナップショットlvmで実行しているときに、I/O操作のパフォーマンスが大幅に低下します。見てください ここ 。彼らがmysqlについて話しているという事実を無視してください。I/ O操作はI/O操作です...どのようなデータがLVMに置かれていても。
私はlvmスナップショットを使用して、DomU Lvを別のVgに別の1つをコピーします。各ドメインには3つのバックアップ「ノード」があり、それを破棄します。
その後、スナップショットは破棄され、バックアップLvは次のラウンドまで残ります。作成する復元がある場合は、バックアップVgからソースLvを選択し、それをドメインLvにコピーするだけです。
たまに、バックアップLvが別のサーバーのイメージファイルにダンプされます。
これらはすべてスクリプトによって自動化され、2日ごとにバックアップが行われ、毎週ダンプが行われます。
私は「パニック」モードも念頭に置いていました。ドメインLvは復元されますが、スナップショットから実行され、2時間ごとにリセットされて、適切な防御策が整うまで、深刻なハッキングの場合にサイトをオンラインに保ちます。 。
「パニックモード」の防衛線のアイデアはどうなったのですか？