以前の IT 部門が残した、特に厄介な問題があります。私たちは複数のスナップショットを実行していますが、誰もそれを統合しようとは思いませんでした。おそらく、VMWare のスキルが十分で、統合する必要があることに気付かなかったのでしょう。そのため、次のような問題が残っています。
画像が読み込まれないと仮定すると、次のようになります。
- ->VM 343.7GB
- --> スナップショット 1 2018 年 5 月 14 日、150 GB
- ---> スナップショット 2 2018 年 6 月 13 日、9.03 GB (スナップショットの VM のメモリは: いいえ)
- ----> スナップショット 3 2018/06/13、31.19 GB
- -----> スナップショット 4 2018/06/14、386.24 MB
- ------> スナップショット 5 2018/08/27、45.43 GB
- -------> ここです (わーい) 59.5 GB
調べてみたところ、最善の解決策は次のようにすることのようです。
- VM ファイルのバックアップを作成します。できれば、VM の電源をオフにした状態でバックアップしてください。VM 全体を別の場所にコピーするだけで十分です。
- スナップショットを削除します。理想的には、業務時間外に行う必要があります。統合には時間がかかります。かなりの時間がかかります。VM をオフにすると、処理が速くなります。
- VM が無傷かどうかを確認し、無傷でない場合はバックアップを復元します。ソース:VMWare 古いスナップショットの統合
私の質問は次のとおりです。
これらのスナップショットはかなり長い間実行されており、最も古いものは 2018 年から実行されています。私が読んだ内容に基づくと、この時点で VM が完全に破損するわけではないにしても、ある程度の劣化を引き起こす可能性があります。
- 上記の修正を試みるのは時間をかける価値がありますか?
- そうでない場合は、サーバーに保存されているデータベースをバックアップして、サーバーを元に戻したほうがよいでしょうか?
私の理解が正しければ、元に戻すとスナップショットが作成される前の状態に戻り、スナップショットで行われた変更は破棄されます。一方、スナップショットを削除すると、行われたすべての変更が 1 つに統合されます。(VMWare の奇妙な用語)
また、これはシンプロビジョニングされたサーバーです。ディスク容量が不足したことがこの問題を発見するきっかけとなり、現時点では約 4 GB 残っています。
答え1
「仮想マシンのスナップショットを統合するのに必要な時間を見積もる（2053758）」によると、参考文献VMがパワーオンの場合、統合中に追加のDeltaファイルが作成されます。これはNOTESセクションにあり、次のように記載されています。
仮想マシンの電源がオンのときにディスク統合が開始されると、変更されたブロックを追跡するための追加のデルタ ファイルが作成され、統合の最後にベース ディスクに書き込まれます。ただし、現在のスナップショットではない 1 つのスナップショットのみを削除する場合は、追加のデルタ ファイルは必要ありません。
「現在のスナップショットではない 1 つのスナップショットのみを削除する場合、追加のデルタ ファイルは必要ありません。」 古いスナップショットから新しいスナップショットの順に 1 つずつ削除すると、最新のスナップショットに到達するまで追加のドライブ領域は消費されません。これはバックグラウンドで実行されます。
VMwareコミュニティスレッドhttps://communities.vmware.com/thread/560315にもこの問題があります。最悪の場合、ベース/親ディスクはスナップショット内のデータ量までしか拡張できません。
さらに、ESX 3.5 および ESX 4.0 でのスナップショットの統合に関する VMware KB がこちらにあります (パッチ更新が必要です)。ESX 5 以降にはこの機能が組み込まれており、同じ操作を実行します。これは、私がリンクしたコミュニティのディスカッションと同じポイントをカバーしています。参考文献。
したがって、追加のスペース要件に対する私の答えは、「最初に VM をオフにすれば、追加のスペース要件はありません」です。または一度に 1 つのスナップショットを古いものから新しいものへと削除でき、解放されたスペースを使用して、電源がオンになっている間に最新のスナップショットを削除できます。
スナップショットを数年前に戻すと、独自の問題が発生します。コンピューター マシン パスワードが本来のものではなくなるため、ドメインの信頼が失われます。提供したタイムスタンプに基づいて、1.5 年間の Windows アップデート、その他のサード パーティ アプリケーション アップデート、または手動で実行したアップデートも失われます。GPO 経由で取得されなかったレジストリの変更。設定。ドキュメントやダウンロード フォルダーなど、他の場所に保存されているデータも失われます (バックアップしていない場合)。これらはすべて元に戻す必要があります。
破損が懸念される場合は、VM をシャットダウンし、ディスク ファイルを追加のストレージにコピーして、オプションとして言及されているように統合を試みてください。または、スペースの問題については既に言及されているので、別の場所にスペースがある場合は、新しいサーバーを構築してデータベースを移行するだけです。
答え2
あなたの質問が何なのかよく分かりませんので、両方に答えてみようと思います。
スナップショットは「長期バックアップ」を目的としたものではないため、そのディスクを統合することは間違いなく望ましいことです。スナップショットを作成すると (簡単にするために VVOL は無視します)、vSphere は VM ディスクの VMDK ファイル (VM の HDD を表すデータストア上のファイル) を「フリーズ」し、すべての変更を別のデルタ ファイルに書き込み始めます。このファイルは元の VMDK と同じサイズまでしか大きくなりません (おおよそですが、追加のオーバーヘッドが発生する場合があります)。その後、2 番目のスナップショットを作成すると、最初のデルタ ファイルは再び「フリーズ」され、vSphere は 2 番目のデルタ ファイルを開始します。
その後、スナップショットを削除すると、vSphere はデルタ ファイルを取得し、すべての変更を元の VMDK に書き戻します。ただし、パワーオン状態の VM に対してこの処理を実行している間、VM からの変更を書き込む場所が必要になるため、スナップショットを統合している間、VMDK への変更を保持するための一時デルタ ファイルが作成されます。完了すると、はるかに小さい一時デルタ ファイルが再度統合され、一時ファイルを統合している間、ディスク I/O を静かにするために、通常は VM がほんの一瞬停止します。
ただし、中間スナップショットを削除すると、vSphere にはすでに別の新しいデルタ ファイルがあるため、VM に影響を与えることなく処理を実行できます。大きなスナップショットの削除の影響を最小限に抑えたい場合は、これを悪用できます。新しいスナップショットを作成し、バックグラウンドで古いスナップショットを削除し、完了したらはるかに小さいスナップショットを削除します。
元に戻す方法は少し異なります。ここでは、VM の状態をロールバックしますが、リソースの消費量が大幅に少なくなります。デルタ ファイルを削除し、元の VMDK で VM を再起動するだけです (メモリのスナップショットを作成して、VM を電源オンの状態に戻すこともできます)。
ですから、これらすべてを知った上で;
パフォーマンスへの影響により少し遅くなっているものの、VM が正常に動作している場合は、次のようにしてください。
- VMのバックアップが適切であることを確認する
- 速度を上げるためにVMの電源を切る
- 最も古いものから順に、すべての中間スナップショットを削除します。
- 最後のスナップショットを削除する
- オプションが利用可能な場合は、ディスクの統合を実行します。
VM が壊れている場合は、電源をオフにして、バックアップからコピーを復元するか、再構築してください。古いスナップショットに戻すのは最後の選択肢です。スナップショットは、「作業中に誤って C: ドライブ全体を削除してしまったので、30 分前に作成したスナップショットに戻します」という状況を想定したものであり、バックアップではありません。