ext4でフォーマットされたRAID5 LVが完全に占有する7つのディスクVGを持つAzure VM(Ubuntu 20.04)を継承しました。
バックアップを実行する必要があり、Azure Backupを使用してVGを含むAzureディスクのスナップショットを作成したいと思います。
Azure ディスク スナップショットはある時点で一貫性がないため、ファイル システムの整合性と LVM メタデータの理由により、バックアップの実行中にストレージを固定する必要があります。私の作業量は余裕があります。生のディスクブロックを一時的に変更できないようにする最良の方法を見つけようとしています。
fsfreeze
- ファイルシステムの凍結、スナップショット撮影、解凍後のスナップショットへの切り替え方法をテストしました。
限られたテストでは、これはうまくいきます。 「復元された」ディスクを再交換すると、LVMにひどいことは見えませんが、あまりにも多くのテストしか実行できません。もし私のディスクメタデータが一貫していないため、見つからない場合が1%あります。
高すぎるレベルで活動をロックするのが心配です。アクティブではファイルシステム操作は発生しませんが、FIFREEZE
ioctl
LVMがメタデータの更新、RAID関連のアクティビティなど、あらゆる種類の低レベルの操作を実行できなくなりますか?
dmsetup suspend /dev/mapper/my-lvol
それからこれを試しました。感じるより良い解決策が欲しい。
テスト設定:
fsfreeze
echo 3 > /proc/sys/vm/drop_caches
sync ; sync
(古い習慣は簡単に死ぬ:)fsfreeze -f /export
dd if=/dev/mapper/my-lvol of=/dev/null status=progress
完了するまで実行しますdd
。固定ファイルシステムを介してアクセスしていないため、これが機能することを認識していますが、Azureディスクが変更されていないと仮定すると、LVMがまだ低レベルで作業を実行できるかどうか疑問に思います。
dmsetup suspend
echo 3 > /proc/sys/vm/drop_caches
sync ; sync
dmsetup suspend /dev/mapper/my-lvol
dd if=/dev/mapper/my-lvol of=/dev/null status=progress
dd
一時停止がある限りブロックされます。まだアクセスできるdd
機器がありますが、ある程度はそうすると予想しました。rmeta
rimage
このdmsetup
オプションを使用すると、保留中のジョブsyslog警告が表示されますjbd2
。スタックトレースは、ログトランザクション(jbd2_journal_commit_transaction()
)をコミットしようとしていることを示しています。これはすべてLVが本物ただし、一貫性のない状態でファイルシステムのスナップショットを撮っていて、スナップショットにロールバックした場合にログを再生する必要があるかもしれません。私たちのRPOはいくつかのロールバックを可能にしますが、理想的にはこれらのリスクを排除するソリューションを設計したいと思います。
私が放棄したオプション
- ファイルベースのバックアップ:可能ですが、最初は固定スナップショットよりも設定と管理がより複雑に見えます。
- LVを一時的にスナップショットしてバックアップします。 VGがいっぱいで、ディスクを追加したり、VGのサイズを変更したくありません。
質問
ここにどんな意見でも送っていただければ本当に感謝します。ご覧のように、Linuxファイルシステム/ブロックIOの私の理解は限界です(多分それ以上の可能性があります)。
- 全体的に、固定/一時停止は、一貫した特定の時点のスナップショットを取得するための実行可能なソリューションのように見えますか?
- まだ十分に深くないですか?
jdb2
トランザクションを作成できないため、より低いレベルでメタデータ更新を実行できますか、または継続できlvm
ますか?dm
ありがとう、チーム