バックアップから復元した後、スパース仮想ディスクがフルサイズを消費するのはなぜですか？
スパース仮想ディスクは、復元時にゼロで埋められた領域が実ブロックとして書き込まれるか、イメージがシック形式で再作成されると、完全割り当てになります。
スパースVHD、VHDX、raw、QCOW2イメージは、割り当て済み領域にのみストレージを使用しながら、大きな論理容量を報告できます。バックアップではファイル内容が完全に保持されていても、ホール、未割り当てクラスター、破棄状態、シンプロビジョニングのメタデータに関する情報が失われることがあります。復元されたゲストは正常に起動できても、ホスト上のファイルが仮想サイズ全体を占有している場合があります。唯一の復元コピーをコンパクト化または変換する前に、形式と割り当て状態を確認してください。
論理サイズと実際の割り当てサイズを比較する
イメージ形式、仮想サイズ、見かけ上のファイルサイズ、ホストで割り当てられたブロック数、保存先ファイルシステム、復元されたイメージがスパースまたは事前割り当てとして設定されているかを記録します。
Microsoftは、スパースファイルは未割り当て領域に対してゼロを返す一方で、より大きな公称ファイルサイズを維持すると説明しています。そのため、仮想サイズと物理的な使用量は別々に測定する必要があります。
ファイルブラウザーだけに頼らず、割り当てを認識できるツールを使用してください。仮想サイズと割り当て済みサイズが同じになっている場合、復元時にホールが実体化されたか、固定形式が選択された可能性があります。
バックアップでスパースホールが保持されたか確認する
バックアップジョブのファイルコピー、ブロックコピー、アーカイブ、圧縮、スパースファイルに関するオプションを確認します。割り当て済みエクステントを保存したのか、論理ディスク全体を連続したバイトストリームとして読み取ったのかを特定してください。
GNU Coreutilsの説明によると、コピー ツールは保存先でスパースホールを再作成する必要があります。そうしないと、長いゼロの連続が通常の割り当て済みブロックとして書き込まれる可能性があります。
内容が正しい復元結果であっても、割り当てメタデータが保持されたことの証明にはなりません。同じバックアップおよび復元経路を使い、既知のホールを含む小さなテストイメージを比較してください。
イメージ変換でスパース化が無効になっていないか確認する
バックアップオブジェクトから復元イメージまでのすべての変換手順を確認します。入力形式、出力形式、事前割り当てオプション、スパースしきい値、コピーオフロードが使用されたかどうかを記録してください。
QEMUによると、qemu-imgの変換ではゼロセクターを検出して抑制できます。一方、ゼロのスパースしきい値や、サポートされていないコピーオフロード経路によって、保存先が完全割り当てになる場合があります。
仮想マシンの実行中にイメージを再変換しないでください。検証済みのコピーを使用し、復元イメージを置き換える前に仮想ディスクの内容を比較してください。
保存先ファイルシステムがスパースファイルをサポートしているか確認する
保存先NASのファイルシステムと、すべての中間ステージングボリュームでスパースファイルの対応状況を確認します。互換性のないファイルシステムに復元された場合、最終ストレージに到達する前にホールが失われる可能性があります。
シン割り当ては、論理サイズだけでなく、ストレージオブジェクトのプロビジョニング特性にも依存します。保存先が大容量ファイルに対応していても、バックアップアプリケーションがホールを再作成しなければ、イメージが完全割り当てオブジェクトとして復元されることがあります。
ステージングまたは保存先のファイルシステムがホールを保持できない場合、最終的なVMデータストアに到達する前にファイルが完全割り当てになる可能性があります。まず使い捨てのイメージでスパース対応をテストしてください。
シックな復元形式とゲストの空き領域を区別する
復元されたディスクが、raw事前割り当て、rawスパース、固定VHD、動的VHDX、QCOW2のいずれであるかを特定します。ゲストの空き領域が、ホスト側のホールに自動的に変換されるわけではありません。
Red Hatは、事前割り当て仮想ディスクとスパース仮想ディスクを区別しています。事前割り当てディスクは全容量を直ちに予約し、スパースディスクはデータが書き込まれるにつれてストレージを割り当てます。
復元先が意図的にシック形式だった場合、完全割り当ては破損の証拠ではなく、想定された動作です。パフォーマンスと容量のトレードオフを踏まえ、シン形式に戻す価値があるか判断してください。
サポートされたオフライン方式でゼロ化領域を再利用する
仮想マシンをシャットダウンし、別のバックアップが存在することを確認したうえで、削除されたゲストブロックがゼロ化または破棄されているかを確認します。ゲストの空き領域に古いゼロ以外のデータが残っている場合があります。
Red Hatのvirt-sparsifyワークフローは、認識された空き領域をホスト側のスパース領域に変換します。また、稼働中のディスクイメージに対して実行しないよう警告しています。
コンパクションは複製したイメージに対してのみ実行し、その後ゲストのファイルシステムを検証してください。アプリケーションレベルのテストに合格するまで、元の復元イメージを保持します。
事前割り当てとホールパンチングの動作を確認する
復元アプリケーションが信頼性やパフォーマンスのために保存先を事前割り当てしたかどうか、また保存先が後から領域を解放できるかどうかを確認します。
Linuxのfallocateインターフェースは、実ブロックの割り当てとホールのパンチングを区別しています。これは、ゼロを書き込むことと領域を解放することが同じ操作ではない理由を示しています。
形式が不明な仮想ディスクに対して直接ホールパンチングを行わないでください。メタデータとクラスター配置を理解しているハイパーバイザーまたはイメージユーティリティを使用してください。
置き換える前に復元ディスクを検証する
コンパクションしたコピーを単独で起動し、ファイルシステム、アプリケーション、スナップショット、ゲストの空き領域を確認します。その後、代表的なファイルのハッシュと、仮想ディスクが報告する構造を比較してください。
ZimaSpaceのホームサーバー復旧チェックリストには、以前のコピーを削除する前にストレージとアプリケーションの復旧を証明するための関連要件がまとめられています。
復元されたディスクが意図したシン形式を維持し、ホストで割り当てられた領域が実際のゲストデータを反映し、仮想マシンが起動、ワークロード、バックアップ、復元の検証に耐えれば、問題は解決です。変換でエラーが発生する場合や、プラットフォームがシックプロビジョニングを必要とする場合は、完全割り当てのイメージを保持してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
