今回は、実運用環境において、必須ともいうべき「バックアップ」と「災害対策」の機能について、その概要を学び直します。最初は単体のHyper-Vホストにおけるチェックポイントとバックアップの機能について見ていきましょう。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
仮想化基盤におけるバックアップの話をする際、「スナップショット機能でバックアップを取得しているから問題ない」という回答を聞くことが少なからずあります。
Microsoftの「Hyper-V」では「チェックポイント」と称される「スナップショット」機能は、仮想マシンの状態や仮想ハードディスクの状態を「チェックポイントを取得した瞬間」の状態で保持し、任意のタイミングでチェックポイント取得時点へ巻き戻す機能になります。
チェックポイントを取得しているので、何か問題があればチェックポイントの取得タイミングまで巻き戻せる、だからバックアップを取得していることと同義である、というのが、チェックポイントをバックアップとして捉えている理屈です。
では、チェックポイントはどこに格納されているのでしょうか?
本連載第13回「いまさら聞けないHyper-Vのストレージ機能」でも触れましたが、Hyper-Vで仮想マシンのチェックポイントを取得した際には、チェックポイント取得後の差分ディスクとして拡張子「.avhdx」の仮想ハードディスクファイルが作成されます。この仮想ハードディスクファイルは仮想マシンのもともとの仮想ハードディスクと同じフォルダに保存されるため、これらの仮想ハードディスクを格納している物理ディスクに障害が発生した場合には、チェックポイントごと消失してしまうことになります。
「そういう場合のために物理ディスクを冗長化しているのだから、物理障害でデータロストすることはないのでスナップショットはバックアップに足り得る」という意見も耳にすることがあります。
しかし、昨今話題に上る「ランサムウェア(身代金要求型マルウェア)攻撃」を受けた場合、物理ディスクに障害が発生せずとも「仮想ハードディスクファイルが暗号化され、仮想ハードディスクとして使用できない」状態になると、スナップショットではバックアップにならないことが理解いただけるかと思います。
バックアップには、仮想化基盤と切り離された環境にデータを保管し、仮想化基盤が全損しても復旧可能な状態を維持できていることが求められます。
では「チェックポイントは不要なのか?」と思うかもしれませんが、そうではありません。チェックポイントは素早く仮想マシンの状態を保存可能であり、チェックポイント取得時点への巻き戻しも非常に高速で実現できます。仮想マシンにパッチを適用するなど、システム変更作業の直前でスナップショットを取得し、問題が発生した際には素早くチェックポイント取得時点まで巻き戻すという、いわば作業前の状態保存には最適な仕組みといえます。
バックアップとチェックポイントは用途が異なる保存方法だということを理解し、シチュエーションごとに使い分けることが重要、ということを理解すべきでしょう。
前項でも紹介した通り、チェックポイントは「仮想マシンの状態」を素早く保存できる機能です。遠隔地保管が可能なバックアップを取得するほどでもないが、何かあった場合に備えて今の状態を保存しておきたい、という場合に最適です。
チェックポイントには「標準チェックポイント」と「運用チェックポイント」の2種類があります。どちらのチェックポイントを取得するかは、仮想マシンの設定で個別に決められます(画面1)。
「標準チェックポイント」は、「Windows Server 2012 R2」のHyper-V以前で実装されていたチェックポイント(スナップショット)と同一のものになります(注)。
【注】Windows Server 2012までは「スナップショット」と呼ばれていましたが、System Center製品などとの名称の統一を図る目的で、Windows Server 2012 R2から「チェックポイント」に変更されました。
標準チェックポイントは、実行された瞬間の仮想ハードディスクと仮想マシンのメモリ状態のチェックポイントを取得します。メモリ状態も保存されるため、アプリケーションの実行状態なども保管されます。画面2は標準チェックポイントを取得した仮想マシンになりますが、取得したチェックポイントを選択すると、画面(ここではコンソールログイン済みの状態で取得したため、デスクトップ画面)が確認でき、OSが起動状態で保存されていることが分かります。
標準チェックポイントのメリットは、メモリ状態も含めて取得するため、アプリケーションの状態も元に戻せることです。つまり、仮想マシンのOSの状態をそのまま元に戻せるのです。例えば、標準チェックポイントを取得してバッチジョブを実行し、エラーが発生したとします。チェックポイントを適用して元の状態に戻すことで、エラー発生前の状態に復帰できます。
しかし、メモリ状態も巻き戻ることになりますので、Active Directoryドメインコントローラーや他のノード上のデータベースと同期しているデータベースなどでは、チェックポイントで元の状態への復元を行うと他のノード上のデータとの間で整合性に問題が生じる可能性がありますので、適用には十分注意してください。
標準チェックポイントで発生し得る問題に対応するために、「Windows Server 2016」で新たなチェックポイント方式「運用チェックポイント」が実装されました。
運用チェックポイントではメモリ状態は保存されず、仮想ハードディスクのみが保存されます。また、運用チェックポイントでチェックポイントを取得した場合、ゲストOSと連携してディスク整合性を確保した状態のチェックポイントを取得できます。
画面3は運用チェックポイントを取得した際に表示されるメッセージです。「ゲストOSのバックアップテクノロジーを使用してチェックポイントを取得した」と記述があります。
ゲストOSがWindows OSの場合は、「ボリュームシャドウコピーサービス(Volume Shadow Copy Service:VSS)」と連携して取得することで、仮想マシンの整合性がある状態でチェックポイントが取得されます。Linux OSの場合は「ファイルシステムフリーズ(fsfreeze)」を利用して整合性を確保します。
運用チェックポイントでは画面3にも記述されている通り、アプリケーションの状態、つまりメモリ状態のチェックポイントは取得されません。ディスク状態だけであるため、取得したチェックポイントの画面を確認すると、電源オフの状態と同じように画面は表示されません(画面4)。
チェックポイントを適用すると、仮想マシンは電源オフの状態で復元されます。そのため、仮想マシンでは「システムは正常にシャットダウンする前に再起動しました」というシャットダウンに関するログが出力されます。整合性が確保されているため、障害が発生する可能性は低いと捉えて問題ないでしょう。
標準チェックポイントと運用チェックポイントのどちらでチェックポイントを取得するかは、仮想マシンごとに設定可能です。チェックポイントの取得方法はどちらの種類であっても同じです。
「Hyper-Vマネージャー」から仮想マシンを選択し、コンテキストメニューもしくは右ペインのメニューから「チェックポイント」を実行することで取得できます(画面5)。特に確認ウィンドウは表示されず、そのままチェックポイントが取得されます。
チェックポイントの適用も取得されているチェックポイントの種類によらず、適用したいチェックポイントを選択してコンテキストメニューもしくは右ペインのメニューから「適用」を実行します(画面6)。
チェックポイントの適用では確認のウィンドウが表示されるので、現在の状態でチェックポイントを取得してから、指定したチェックポイントを適用するか、そのまま現在の状態を保存せずに適用するかを選択してからチェックポイントを適用します(画面7)。
チェックポイントを取得した仮想マシンの仮想ハードディスクには、チェックポイントを取得するたびに拡張子「.avhdx」の差分ディスクが追加されていきます。画面8はチェックポイントと仮想ハードディスクの対比になります。赤枠の差分ハードディスクが現在書き込みを行う仮想ハードディスクとなり、他の仮想ハードディスクに対する書き込みは行われません(差分仮想ハードディスクのため、過去ディスクにしかないデータの読み込みは行います)。
前項でも解説した通り、チェックポイントは差分仮想ディスクでの実装であり、これらのファイルのいずれかで論理障害が発生すると差分ディスクのチェーンがつながらなくなり、結果としてその仮想マシンは起動不可になります(画面9)。
また、壊れたファイル以降のチェックポイントを破棄すること(壊れた差分ディスクを含まない状態のチェックポイントの時点に巻き戻す)で仮想マシンを起動できますが、障害が発生した差分ディスク以降のデータを読み出すことは困難といえるでしょう。
よって、チェックポイントはバックアップには相当しないと考えるのが妥当である、とご理解いただけるのではないでしょうか。
Hyper-Vでは、仮想マシンを可搬性のある状態に保管し直すことが可能です。
この作業は「エクスポート」と呼ばれるもので、可搬性があるため、Hyper-Vホストとは別のファイルサーバなどに保管することもでき、別のHyper-Vホストに「インポート」することでエクスポートした時点の状態を復元することもできます。
エクスポート作業と、エクスポートしたデータの別筐体(きょうたい)保管を組み合わせることで、仮想マシンのバックアップ手法として利用できます。エクスポート作業は非常に簡単で、Hyper-Vマネージャーでエクスポートしたい仮想マシンを選択し、コンテキストメニューもしくは右ペインのメニューから「エクスポート」を実行するだけです(画面10)。
エクスポート先のフォルダを指定するとエクスポートが開始されます(画面11)。
指定したフォルダ配下に仮想マシン名のフォルダが作成され、その配下に仮想ハードディスクや構成ファイルといった必要なファイルがフォルダごとに保存されています。このフォルダを丸ごと保管、もしくは移動することで、バックアップとして利用することもできます。
なお、エクスポートする際は、仮想マシンを停止状態にすることが推奨されます。稼働中の仮想マシンをエクスポートすることも可能ですが、自動的にチェックポイントが作成され、ディスク整合性がとれているチェックポイントの状態がエクスポートされます。
エクスポートした仮想マシンは、簡単に他のHyper-Vホストにインポートできます。インポートもHyper-Vマネージャーから実施します(画面12)。
インポートの際は、仮想マシンをエクスポートした際に作成される仮想マシン名のフォルダを指定します。このフォルダ配下に、インポートに必要な全てのファイルが含まれています。「インポートウィザード」が指定されたフォルダを読み込み、インポート可能な仮想マシンを検出すると仮想マシン名が提示されるので、問題なければ先に進めます。インポートする仮想マシンを選択すると、インポート方法の選択画面になります(画面13)。
仮想マシンをエクスポートしたフォルダを、インポートするHyper-Vホストにコピーしたと思いますが、そのコピー先フォルダのまま仮想マシンをインポートする場合は「インプレースで登録」を選択します。
あらためてインポート先のフォルダを指定したい場合には、「復元」ないしは「コピー」を選択します。「復元」と「コピー」の違いはウィザードにも記述されている通り、「仮想マシンのID(VM ID)を引き継ぐか、新規設定するか」の違いになります。
「復元」を選択した場合は、VM IDをそのまま引き継ぐため、いわば「Hyper-Vホスト間で移行された仮想マシン」という扱いになります。つまり、全く同じ仮想マシンが異なるHyper-Vホスト上で稼働することになります。画面14は「復元」のオプションでhost39にインポートした仮想マシンになりますが、VM IDはエクスポートしたhost33上の仮想マシンと全く同じVM IDであることが分かります。
対して「コピー」オプションでインポートした場合は、新しいVM IDが割り当てられた仮想マシンがインポートされます(画面15)。host33上の仮想マシンと全く異なるVM IDが割り当てられており、Hyper-Vとしては「全く新規の仮想マシン」となっていることが分かります。
つまり、エクスポートした仮想マシンを新しいHyper-Vホストに「リストア」するためにインポートを行う場合は「復元」オプションを、テストなどで既存環境への影響を避けたい場合は「コピー」オプションを選択するのがよいでしょう。
インポート後の仮想マシンを確認すると、チェックポイントが存在する状態でエクスポートした場合には、チェックポイントまで復元されていることが分かります(画面16)。
このため、稼働中の仮想マシンで何かしらの問題が発生した際、エクスポートすることでその瞬間の状態をバックアップし、他のHyper-Vホストにインポートした上で再現テストを行うなどの対応が可能です。
Hyper-Vの基本機能にはバックアップがありません。従って、バックアップを取得したい場合には、Microsoftまたはサードパーティーのバックアップソフトウェアを利用/導入する必要があります。
Microsoft純正のバックアップツールは以下の3つがあります。
「System Center Data Protection Manager」(DPM)は、Microsoftの運用管理ソリューションである「System Center」スイートの中のバックアップツールです。Hyper-Vのバックアップにとどまらず、「Microsoft SQL Server」などのアプリケーションのバックアップにも使用可能な非常に高機能な製品です。ただ、カバーできる範囲が広過ぎるため、ここでは取り扱いません。DPMに関しては、Microsoftの公式ドキュメントをご確認ください。
「Windows Serverバックアップ」は、Windows Serverの標準機能です。そのため、追加コスト不要で、Windows Serverがあれば利用できます(画面17)。
画面17の通り、Windows Serverバックアップは仮想マシンのバックアップにも対応しており、仮想マシンを指定することでバックアップを取得できます。また、稼働中の仮想マシンのバックアップも可能で、バックアップのために仮想マシンを停止する必要はありません。
仮想マシンの他、Hyper-Vホストのバックアップも取得できます。また、Hyper-Vホストの設定のみをバックアップすることも可能です。画面18は仮想マシンをはじめとするHyper-Vで認識している対象の選択画面になります。
この中に「Host Component」という項目があります。これはHyper-Vホストの「Hyper-Vの設定」になりますが、「Host Component」だけをバックアップしてもHyper-Vホストの設定は戻りません。Hyper-Vの完全な設定をバックアップしたい場合には、Hyper-Vホストのシステム状態を含むバックアップが必要になります。
かなり古いドキュメントになりますが、Host Componentに関する言及があった記事になりますので、参考にしてください。
Windows Serverバックアップは仮想マシンのバックアップ/リストアは可能なものの、スケジュール機能が限定的であったり、リモートのHyper-Vホストの仮想マシンはバックアップできなかったりと、一部のバックアップシナリオにしか対応できません。
また、Windows Serverバックアップは、本連載第14回で紹介した「フェールオーバークラスタリング」でクラスタ化した仮想マシンのバックアップを取得できない(仮想ハードディスクファイルはバックアップ可能)ため、エンタープライズ環境の運用での使用はなかなか難しいかもしれません。
そのような「クラスタ環境で運用している仮想マシンのバックアップを取得したい」「複数のHyper-Vホスト上の仮想マシンのバックアップを取得したい」「複数のスケジュールでバックアップを取得したい」「遠隔地(Azure)にバックアップを転送したい」といった機能が要求される場合は、2つ目に挙げた「Azureバックアップ」がお勧めになります。
Azureバックアップは、Microsoftのクラウドサービスである「Microsoft Azure」が提供するバックアップサービスであり、オンプレミスのHyper-Vホスト上の仮想マシンもバックアップできます。また、バックアップをAzureに転送することで、オンプレミスのバックアップデータが消失しても、Azure側に転送したバックアップデータをリストアすることが可能です。
AzureバックアップによるHyper-V仮想マシンのバックアップを取得するには、「Microsoft Azure Backup Server(MABS)」をオンプレミス側に展開して、MABSのローカルディスクにバックアップを取得して、定期的にMicrosoft Azureに転送します。
画面19はMABSで仮想マシンのバックアップを取得し、Microsoft Azureにバックアップを転送したものになります。最新のバックアップはローカルディスクにしかないものの、クラウド側にも少し古いバックアップが転送されています。
そのため、オンプレミスにあるMABSに障害が発生しても、Microsoft Azure側にバックアップが残っているため、そこからのリストアが可能です。バックアップ要件に遠隔地バックアップが含まれている場合には、Azureバックアップは強い味方になるでしょう。
また、画面19では「クラスターネットワーク名:Test-VM01.HVCluster10」と表示されている仮想マシンのバックアップを取得していることが確認できます。こちらの表示の通り、Azureバックアップはクラスタ化された仮想マシンのバックアップを取得できます。なお、クラスタリソースとしての仮想マシンが残っている状態であれば、そのままクラスタリソースにリストアすることも可能です。Azureバックアップの詳細に関しては、Microsoftの公式ドキュメントをご確認ください。
本稿執筆時点(2026年3月中旬)において、MABSのサポート対象に「Windows Server 2025」は含まれておらず、正式サポートは「Windows Server 2022」までとなっています。そのため、現時点でWindows Server 2025 Hyper-Vのバックアップが要件に含まれている場合、別のソリューションを採用する必要がある点に注意してください。
Microsoftのバックアップソリューション以外にも、数多くのサードパーティーのバックアップソリューションがあります。Hyper-Vに対応したバックアップソリューションも数多くありますので、「キーマンズネット」などで探してみてください。
ここまでは仮想マシンのバックアップを主体に見てきましたが、仮想マシンが動作するHyper-Vホストのバックアップも考える必要があります。Windows Serverバックアップやサードパーティーのバックアップソリューションで、Hyper-Vホストのバックアップは可能です。したがって、それらのツールでバックアップを取得し、万が一の場合には迅速なリストア方法を確立して、日々の運用訓練の中でリストアテストも行うべきでしょう。
サードパーティーのバックアップソリューションの中には、USBメディアなどのブータブルイメージでサーバを起動し、指定されたバックアップサーバからイメージをリストアする製品などもあります。そうしたものを利用するのも一つの手かと思います。
また、Hyper-Vホスト上にアプリケーションなどをインストールせず「単純なHyper-Vホスト」として使用している場合は、「Hyper-Vの役割」を導入してネットワークやストレージを設定すれば、すぐに運用可能な状態に持っていける可能性があります。
そうした再インストールによる運用環境の復帰が容易な場合は、あえてHyper-Vホストのバックアップは取得せず、Windows Serverを再インストールしてHyper-Vを再設定し、仮想マシンのみをリストアする、という方法を採ることもできます。
Hyper-Vは、VLAN(Virtual LAN)など仮想マシンのネットワーク設定は全て仮想マシン側で保持しており、Hyper-Vホスト側は仮想スイッチの設定だけとなっていて、個別のVLAN設定などは不要な構造になっています。また、Hyper-Vホストの設定も全てPowerShellで設定可能となっているので、OSインストール後にHyper-V設定用のPowerShellスクリプトを実行して環境を整える、ということも可能と思います。
本連載では触れませんでしたが、フェールオーバークラスタリング構成のWindows Server 2025であれば、フェールオーバークラスターにHyper-Vホストを参加させると、ホストネットワークの設定や仮想スイッチの設定を自動展開する「Network ATC」という機能も利用できます。これにより、物理ネットワークアダプターの設定や仮想スイッチの設定を自動化することが可能です。
もちろん、バックアップソリューションでHyper-Vホストのバックアップを取ることも非常に有用な手段です。ただ、そういった機能を利用するにはコストが発生するので、広い視野でソリューションも勘案し、最適なHyper-Vホストのリカバリー戦略を策定すべきです。
今回は、単体のHyper-Vホストのチェックポイントやバックアップといった仮想マシンの保護手法を中心に概要を見てきました。次回は少し視点を広げ、広域災害を想定した遠隔地保護に関して、Hyper-Vの標準機能である「Hyper-Vレプリカ」やAzureのサービスである「Azureサイトリカバリー」でどのように実現できるのかについて触れていきたいと思います。
株式会社ネットワールド所属。Microsoft MVP for Cloud and Datacenter Management(2012-2025)。現業の傍ら、コミュニティーイベントでの登壇や著作にてMicrosoftテクノロジーに関する技術情報の発信、共有を続けている。ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。近著は『詳解! Windows Server仮想ネットワーク』(日経BP社)。
Copyright © ITmedia, Inc. All Rights Reserved.