スナップショットモードでのみVMバックアップが同じ進捗率でフリーズする場合の対処方法

スナップショットモードでのみ、VMバックアップが毎回同じ進捗率で停止する場合、固定されたディスク上の不良領域よりも、ライブスナップショットまたはゲストのフリーズ処理が原因である可能性が高くなります。

決定的な比較方法は、同じVM、保存先、およびおおよそ同じデータ量を使って、スナップショットモードと停止モードを比較することです。停止モードが以前停止した進捗率を繰り返し通過するなら、固定領域に関する一般的な診断の可能性は低くなり、QEMU Guest Agentのフリーズ／解除、アプリケーションの静止処理、スナップショット対応ストレージ、ライブ書き込みの挙動へ調査を移すべきです。トラブルシューティング中に復元可能な最後のコピーを失わないよう、テスト中も正常に動作する停止モードのバックアップを維持してください。

停止モードでスナップショットの停止地点を通過することを確認する

メンテナンス時間帯に、失敗するスナップショットジョブと同じ保存先へ、停止モードでバックアップを1回実行します。スナップショットモードで通常停止する進捗率、ディスク、スループット、所要時間を記録してください。

Proxmoxのバックアップモード比較では、スナップショットモードではVMを稼働させたままにする一方、停止モードではゲスト実行時の変数の多くが取り除かれると説明されています。

停止モードでも同じ地点で停止する場合は、一般的な「同じ進捗率で停止する」記事に戻り、ソースまたは保存先ストレージのテストを行ってください。停止モードが完了する場合は、以降の実験をスナップショット固有の経路に絞ります。

QEMU Guest Agentのフリーズが引き金か確認する

バックアップログで、guest-fsfreeze-freeze、guest-fsfreeze-thaw、タイムアウト、またはゲストエージェントとの通信エラーを確認します。時刻をゲストのジャーナルまたはWindowsイベントログと照合してください。

ProxmoxのWindowsバックアップ手順では、エージェントが有効になっている場合、ゲストエージェントがfsfreezeを実行すると説明されています。

最初の対策として、ゲストの整合性機能を恒久的に無効化しないでください。制御されたテストで、フリーズ呼び出し自体が停止地点になっているかを確認してから、ゲストエージェントまたはファイルシステムとの連携を修復してください。

正常にフリーズできないファイルシステムを探す

ゲスト内でマウントされているファイルシステムを一覧化します。ループデバイス、ネットワークファイルシステム、bind形式のアプリケーションマウント、データベースストレージ、特殊なコントロールパネル構成なども含めてください。スナップショット開始時に、どのファイルシステムがビジー状態になるかを記録します。

CloudLinuxでは、バックアップ先そのものではなく、fsfreezeによって複雑なゲストがハングする場合があると説明されています。

問題のあるゲストマウントを削除または修正することでスナップショットモードがその進捗率を通過できるようになった場合は、整合性保護を再び有効にし、その依存関係を文書化してください。強制リセットを繰り返すと、バックアップの問題がゲストファイルシステムの損傷につながる可能性があるため避けてください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

フリーズのタイムアウトと転送停止を区別する

バックアップが実質的なデータ転送の開始前、フリーズ要求の直後、またはブロックコピー中の後半のどの段階で停止しているかを確認します。ほぼ0%で停止する場合と、仮想ディスクの途中で停止する場合では、まったく異なる失敗段階を示している可能性があります。

ホスティング関連のナレッジベース事例では、スナップショット処理の開始後にフリーズによってバックアップが無期限に停止する場合があることが示されています。

転送がまったく始まらない場合は、ゲストの静止処理に注目してください。転送が長時間正常に進んでから停止する場合は、ライブ書き込みの負荷、スナップショット層の動作、ストレージのレイテンシを比較してください。

完全なバックアップの外でゲストのフリーズを再現する

プラットフォームとメンテナンスポリシーで許可される場合は、ゲストエージェントのフリーズと解除の動作を個別にテストするか、手動のスナップショット処理中にゲストを注意深く監視します。コンソールを開いたままにし、解除後にゲストが書き込みを再開することを確認してください。

QEMUの課題では、特定のゲストファイルシステム構成で、QEMUのfsfreezeによってVMがロックされる場合があることが記録されています。

フリーズ単独でハングを再現できる場合は、PBSのスループットを調整する前に、そのゲスト側の処理を修復してください。フリーズと解除が正常な場合は、スナップショットストレージとライブ書き込みの相互作用を下流側で調査します。

スナップショットモードが通過するまで停止モードを復旧経路として維持する

便利な機能を調査するために、信頼できるバックアップを犠牲にしないでください。スナップショットモードが複数回正常に完了し、復元テストで結果が確認できるまで、許容できるメンテナンス時間帯に停止モードのバックアップをスケジュールしてください。

Server Faultの事例では、ライブスナップショットの挙動に個別の対応が必要な場合に、停止モードをフォールバックとして利用している実環境が紹介されています。

スナップショットモードが以前の停止地点を繰り返し通過し、バックアップ前、実行中、完了後もゲストが応答し続ければ、修正は完了です。停止モードでも同じ地点で停止する場合は、同じ進捗率で停止するバックアップの一般的な診断に戻るのが正しい分岐です。

よくある質問

停止モードはスナップショットモードの恒久的な代替になりますか？

ダウンタイムを許容できる場合は、信頼できるフォールバックとして利用できます。ただし、ゲストを安全に静止でき、ライブバックアップが安定して完了する場合は、通常スナップショットモードの方が適しています。

バックアップを動作させるためにQEMU Guest Agentを無効にすべきですか？

適切な場合に限り、制御された診断テストとして実施してください。エージェントはシャットダウンや整合性確保にも役立つため、フリーズの根本原因を特定せずに隠すのではなく、問題のある処理を特定すべきです。

問題がfsfreezeなのに、なぜバックアップは同じ進捗率で停止するのですか？

進捗率はディスク上の場所だけでなく、再現性のあるバックアップ処理の段階に対応することがあります。そのため、同じ段階で到達するフリーズやスナップショットへの移行によって、画面上では同じ進捗率が表示される場合があります。