仮想化

サーバー仮想化に関するバックアップと障害復旧

Adam Fazio

 

概要 :

• 障害復旧計画の考慮事項
• 障害復旧の高可用性ソリューション
• Windows Server バックアップを使用したバックアップと復元

障害復旧計画の基本事項
障害復旧と仮想化
物理-バーチャル変換
仮想マシン スナップショット
Hyper-V のバックアップ
Windows Server バックアップ
WSB による VM のバックアップ
考慮事項
WSB による VM の復元
Data Protection Manager
スクリプトによるバックアップ
DiskShadow
まとめ

サーバー仮想化テクノロジが進化し、業界での普及が進むにつれて、組織では、「インフラストラクチャにかかるコストの削減と IT 敏捷性の向上」という仮想化を正当化する最も一般的な理由を超えたところにあるメリットを認識するようになりました。その新たな開拓分野は、仮想化プラットフォームを障害復旧 (DR) 戦略を強化する手段として使用することです。

IT 業界において DR への備えが常に話題に上るのはなぜかというと、1 時間のダウンタイムにより企業は平均 80,000 ～ 90,000 ドルの損失を被り、壊滅的なデータ損失を被った企業が、その後、長期間存続することはまれである、という調査結果が出ているからです。この記事では、マイクロソフトの仮想化プラットフォームを使用した DR の概要を説明し、Windows Server 2008 Hyper-V に関するバックアップと復元のオプションおよび考慮事項を紹介します。

障害復旧計画の基本事項

DR は、停電時に重要なサービスを復元するプロセスで、すべての企業の事業継続計画に含まれているべきものです (事業継続計画とは、このような障害発生時および発生後に企業がどのようにして存続するかを定義するものです)。このような計画は、DR の構想に必要不可欠です。

一部のベンダが提供する DR 自動化テクノロジの中には、そのテクノロジを使用すると、十分に準備を行った詳細な計画を立てる必要がなくなったり、その作業が簡略されたりすると謳っているものがあります。自動化により復旧にかかる時間が短縮され、人の手を必要とする作業が軽減されるのは事実です。ですが、公共広告に耳を傾けてください。テクノロジだけでは災害を軽減することはできません。人とプロセスもテクノロジと同じくらい大切です。

事実、DR の計画段階で発生する制限事項と目的を知らなければ、適切なテクノロジを選択するのは不可能だと言っても過言ではありません。DR の計画全般について説明するのは、この記事の範囲を超えていますが、これらの要素は、適切なテクノロジと実装を選定するうえで重要であることは強調しておきたいと思います。では、DR 計画でテクノロジを選定する際の重要な要因のいくつかを簡単に紹介しましょう。

サービスの定義と優先順位保護するサービス全体で何を定義していて、そのサービスが組織においてどの程度重要であるかを定義します。図 1 は、一般的な DR 計画に含まれる可能性の高い企業向けサービスの一覧です。

サービスを定義したら、各システムと依存関係について、どのような DR 戦略を採用するのかを判断する作業に取りかかることができます。すべてのサービスと依存関係を洗い出して初めて、すべてのミッション クリティカルなサービスに 1 つの DR ソリューションを使用するのはコストが非常に高く、かつ複雑になるため、DR の機能をいくつかのレベルに分けて考える必要があることが判明する場合もあります。

サービス レベル アグリーメント (SLA) SLA は、サービス プロバイダ (IT) とユーザー (組織) 間で締結された、特定のサービスの可用性目標値を規定した合意事項または契約です。SLA は、非常に長いものもあれば、簡潔なものもあります。たとえば、「本電子メール システムでは、通常業務時間帯において 99.95% の可用性を保証し、通常業務時間外において 98% の可用性を保証します。ただし、毎月の定期メンテナンス時間帯は除くものとします。」というような感じです。通常、SLA は複数の段階に分かれており、この段階に IT サービスを当てはめて、定期的に測定することになっています。

運用レベル アグリーメント (OLA) OLA では、ある特定の SLA をサポートするために協力している複数の IT グループ間で成された合意事項を記載したものです。これには、各グループがサービスを提供するプロセスやサービスの提供にかかる時間などが含まれます。SLA の目標値が 99.99% のミッション クリティカルな Web サイトを所有している場合に、そのサイトのコンテンツを格納しているデータベースの SLA が 95% しかないとします。OLA は、この不一致を解明して、IT チームが同じ目標に向かって作業を進められるように調整する役割を果たします。

目標復旧時点 (RPO) と目標復旧時間 (RTO) RTO は、サービスが利用できなくなってから、連続性が失われるまでの時間を定義するもので、RPO は、企業にとって許容範囲と見なされるデータ損失のレベルを定義します。つまり、毎月定期的に測定しているサービスの SLA が 99% である場合、そのサービスの RTO は 7 時間 18 分であると言えます。たとえば、この RTO を 24 時間という RPO と組み合わせると、バックアップの技法とスケジュールを的確に定義できます。

データの保持に関するポリシー組織におけるデータの保持に関するポリシーでは、バックアップを保管する期間と場所を明確に定義しています。通常、このようなポリシーは法律上や規則上の要件を満たすために作成されています。

データの分類データの性質も考慮する必要があります。データを分類すると、すべてのデータで DR について同じレベルで考慮する必要はないということがすぐにわかります。たとえば、単独のデータベースの可用性の要件は、ディレクトリのレプリカを保持している 3 台のドメイン コントローラを伴う Active Directory の可用性の要件とは異なります。同様に、ファイル サーバーのデータを復元する手順は、CRM のデータを復元する手順とは大きく異なる可能性があります。

障害シナリオ復元手順、業務に与える影響、関連コストはシナリオによって異なるため、対応する必要があるすべてのシナリオを定義することが重要です。ご使用の環境の DR 計画を策定する際には、次のような考えられるすべてのシナリオを検討してから、実際に対応するシナリオを決めることをお勧めします。

• サイト全体のデータ損失
• 特定のデータセンターのデータ損失
• 特定のシステムのデータ損失 (オペレーティング システムまたはハードウェア障害)
• データの損失 (データの削除または破損)
• 重要な依存関係の損失

サイト全体のデータ損失と単一システムのデータ損失では、損失を回復する際の考慮事項が大きく異なるのは明らかです。また、SLA に基づいてしきい値を定義することもできます。たとえば、ISP ネットワークの大規模な停電によりサイト全体がオフラインになったとします。この停電により利用できなくなっているサービスの SLA で、サービスの復元に 8 時間、データの復元に 48 時間かかると明記されている場合は、実際にデータを復元することなく、バックアップ サイトにサービスをフェールオーバーさせるのが得策です。というのも、運用サイトへのフェールバックは比較的短時間で行えるからです。

やれやれ。結構な量の情報を提供しましたが、まだ仮想化テクノロジについては何も説明していません。ですが、計画の重要性をあなどらないでください。計画のドキュメントを作成することなく DR を実装することは、「DR に対する期待」でしかありません。

障害復旧と仮想化

DR 計画の基本事項について説明したので、今度は、DR 計画に仮想化を組み込むとどうなるのかについて説明しましょう。仮想化テクノロジを導入したサーバーを使用している多くの企業は、サービスを分単位という短時間で復旧できると報告しているのに対して、物理サーバーを使用している企業では、サービスの復旧に数日から数週間の時間がかかると報告されています。現在、サーバー オペレーティング システム全体は、基になる物理的なハードウェアから切り離された単なる一連のファイルでしかないため、復旧性を考慮する際には、これまでになかった選択肢が使用できるようになりました。

「DR の目的の一部またはすべては、高可用性 (HA) ソリューションで実現できる」というのが、現時点での一般的な見解です。この見解の背後には、物理的に離れている場所にクラスタ ノードがあり、サイト間でデータを同期している場合、障害発生時には、パッシブ ノードで運用を再開して、ほぼリアルタイムで障害から復旧できることがあります。

これは事実ですが、先ほど紹介した障害シナリオを思い出すと、これがすべてのシナリオに適しているわけでないことは一目瞭然です。すべての障害シナリオに備えるには、複数のテクノロジを組み合わせる必要があり、通常は、なんらかの定期的なバックアップを実行することも必要となります。HA を使用しても、すべての停電から保護したり、バックアップ戦略が完全に不要になったりするわけではありません。

Hyper-V を使用する HA では、復旧性を実現するうえで重要な記憶域層の計画を入念に立てる必要があります。たとえば、共有の記憶域を持つ 2 ノードの Hyper-V クラスタでは、記憶域のサブシステムとデータが単一障害点になり得ます。また、これは、クラスタ ノードが別のデータセンターにある場合も同様です。

共有の記憶域を持たない 2 ノードの Hyper-V クラスタでは、他方のノードで記憶域またはデータの損失が発生しても、その状況に対応できます。ただし、これには、記憶域を同期するレプリケーション テクノロジが必要になり、構成が複雑になります (図 2 参照)。

図 2 複数サイトにまたがる Hyper-V クラスタ (画像をクリックすると拡大表示されます)

データのレプリケーションと同期に関しては非常に興味深い進展が見られますが、現在、マイクロソフトがこの分野で提供しているものはありません。Windows Server 2008 の「フェールオーバー クラスタリング – マルチサイト クラスタリング」(microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx) では、一見の価値があるパートナーを紹介しています。また、Windows Server カタログ (windowsservercatalog.com) では、Windows Server 2008 での使用が認定されているレプリケーション テクノロジを提供している記憶域ベンダを紹介していますので、こちらも参考資料としてご覧ください。

ご覧のとおり、ご使用の環境での使用を検討する対象となる HA と記憶域の構成は多数あります。ですから、ビジネス要件を定義し、その要件に基づいて技術的な要件を定義する必要があります。この順序が逆であるのはよくありません。

物理-バーチャル変換

仮想化により類のない復旧の機敏性が提供されるのは明らかですが、仮想化の候補として適切ではない物理システムについてはどうでしょうか。System Center Virtual Machine Manager (SCVMM) には、実行中の Windows サーバーの物理-バーチャル (P2V) 変換を実行する機能が備わっています。この機能を使用すると、物理的なソース サーバーの完全なレプリカであるブート可能な Hyper-V バーチャル マシン (VM) を作成できます。この VM は、敷地や国境を越えて、仮想化の対象となった物理コンピュータと同様にレプリケートすることが可能で、同程度の時間で復旧することができます。

このアプローチは、従来のベアメタル復元と異なり、復旧場所では、運用環境と同数の同じ種類の物理システムは必要ありません。ですから、障害の影響度合いに応じて、復旧に使用するハードウェアを複数のシステムで使用したり、拡張したりすることができます。

SCVMM には、P2V 変換に対応したスケジューラは用意されていませんが、GUI は完全に Windows PowerShell ベースで実行されるので、New-P2V コマンドレットを使用して簡単にスクリプトを作成できます。実際、SCVMM の全ウィザードでは、ジョブの実行に使用するスクリプトが提供されるので、ご使用の環境のテスト P2V からコードをコピーして、ジョブの自動化を図ることができます。図 3 は、サンプル コードです。ご使用の環境で SCVMM の P2V ウィザードを実行して、一意でカスタマイズ可能な Windows PowerShell スクリプトを作成できます。

$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>" 
-Credential $Credential -RunAsynchronously 

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F" 
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External" 
-MachineConfig $MachineConfig 

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig 

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path 
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig 
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM 
-UseHardwareAssistedVirtualization $false -StopAction SaveVM 

仮想マシン スナップショット

VM スナップショットは、厳密にはバックアップではありませんが、差分ディスクと VM 構成ファイルを使用して、ある特定の時点の状態に戻せるようにするものです。VM 内でデータを誤って削除したことが原因で障害が発生した場合、VM はスナップショットにロール バックして、データの破損を元に戻すことができるので、VM は DR 機能と見なすことができます (ボリューム シャドウ コピー サービス (VSS) のスナップショットについては、後で説明します)。

Hyper-V のバックアップ

ホスト ベースのバックアップサーバー仮想化における興味深いメリットの 1 つは、仮想化システムを個別にバックアップする必要がないことです。現在、このようなシステムは、単にホストのファイル システム上に存在するファイルでしかないので、このファイルのバックアップを作成すれば作業完了と言いたいところですが、必ずしもそうではありません。このようなシステムも、メモリ内データ、ディスク上のデータ、システム構成ファイル、および開いているファイルで構成された実行中のコンピュータなので、考慮しなければならないことがあります。では、このような動的な要素を考慮しながらバックアップ データの整合性を確保するにはどうしたら良いでしょうか。

Windows Server のバックアップ機能は、Windows Server 2003 で VSS が登場したときに大きな進歩を遂げました。VSS では、VSS ライタが開いているファイルやアプリケーションのバックアップを使用する際に使用する拡張可能な API の標準セットを提供します (VSS ライタは、整合性のあるシャドウ コピーを提供するのに役立つアプリケーションやサービスにあるフックです)。VSS サービス、プロバイダ、およびライタにより、バックアップ アプリケーションでは、アプリケーションが認識できて、かつ適切に処理できる形でボリュームの特定時点のコピーを迅速に作成できます。

Hyper-V には、独自の VSS ライタが用意されています。このライタを使用するとソフトウェア ベンダは、魅力的なバックアップ ソリューションを作成できます。また、このライタを使用すると、バックアップ アプリケーションでは、実行中の VM のホスト ベースの VSS バックアップを作成することができます。VM で実行されているオペレーティング システムに Hyper-V の統合コンポーネントと VSS サービスがインストールされている場合、ゲスト システムとして実行されているときと同じようにホスト ベースのバックアップが作成されます (このコンポーネントとサービスは、Windows XP SP1 と Windows Server 2003 以降で使用できます)。このバックアップは、実行中の VM に対して行われ、データの整合性は維持されます (図 4 参照)。

図 4 VSS によるバックアップ (画像をクリックすると拡大表示されます)

ただし、ゲスト オペレーティング システムで統合コンポーネントまたは VSS がサポートされていない場合、バックアップ処理では、ゲスト コンピュータが保存された状態であることと、ホスト ベースの VSS スナップショットが特定の時点への復旧に使用できる VM データ ファイルから作成したものであることが必要になります。また、保存された状態の VSS スナップショットが原因で、VM ではダウンタイムが発生します (通常、ダウンタイムは 5 ～ 10 分程度です)。これは、VSS のコピー データに対してテープへの完全バックアップが行われることにより生じるものです。

ゲスト ベースのバックアップ物理的な環境では、サーバーやアプリケーションは個別にバックアップを作成する必要があります。また、このようなバックアップは、当然、仮想化されたデータセンターでも問題なく機能します。仮想化されたデータセンターで VM のバックアップを作成するときにも、同じようなことを考慮する必要があります。たとえば、ネットワーク ベースのバックアップではネットワーク キャパシティの要件を考慮したり、バックアップの時間帯にはシステムのパフォーマンスへの影響を考慮したりする必要があります。ゲスト ベースのバックアップでは、ホスト システムに搭載されていて、すべてのゲストが使用する仮想ネットワークにバインドされた専用の物理 NIC を使用することもできます。

Windows Server バックアップ

Windows Server 2008 には、ホスト ベースまたはゲスト ベースの Hyper-V VM のバックアップを作成するのに使用できる VSS 対応の Windows Server バックアップ (WSB) 機能が用意されています。VSS に完全に対応しているので、実行中の VM のホスト ベースのバックアップを作成することができます。言うまでもありませんが、これは非常に望ましいことです。

ただし、統合コンポーネントがインストールされていない VM では VSS は使用できません。このような場合に使用できるオプションは 2 つあります。1 つは、統合コンポーネントがインストールされていない VM のバックアップに WSB を使用することが可能です。この場合、VM の状態が保存され、バックアップ処理で VM の仮想ディスクと構成ファイルが取得されます。

ただし、この方法は Exchange Server などのアプリケーションには適していません。というのも、アプリケーションでは、バックアップが実行されたことが認識されないため、アプリケーションのログが、切り捨てられず、そのまま維持されるからです。また、VM ではダウンタイムが発生します (ダウンタイムの時間はバックアップにかかる時間によって異なります)。

もう 1 つのオプションとしては、NTBackup または WSB のどちらかを使用して、物理コンピュータの場合と同様に、VM 内からバックアップを実行できます (使用するツールは、VM で実行されている OS によって異なります)。次は、統合コンポーネントがインストールされていて、WSB がサポートされているゲスト OS で WSB を使用する方法をご紹介しましょう。

WSB による VM のバックアップ

Hyper-V では、WSB で使用するように VSS ライタが自動的に登録されることはありません。WSB で Hyper-V のバックアップがサポートされるようにするには、図 5 に示すレジストリ キーとレジストリ値を手動で追加する必要があります。このレジストリ キーと値は、コマンド ラインで次の構文を使用して追加できます。

reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v

WSB ではバックアップの実行時に、このキーと値を検索するので再起動は必要ありません。エントリが設定されたかどうかは、次のコマンドを実行して確認できます。

reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s

では、次は WSB のインストール方法を紹介しましょう。[スタート] ボタンをクリックし、[サーバー マネージャ] をクリックします。左側のウィンドウで [機能] をクリックし、右側のウィンドウで [機能の追加] をクリックします。[機能の選択] ページで [Windows Server バックアップの機能] を展開し [Windows Server バックアップ] チェック ボックスと [コマンドライン ツール] チェック ボックスをオンにします。それから、以下の手順に従います。

1. [スタート] ボタンをクリックし、[管理ツール] をクリックし、[Windows Server バックアップ] をクリックします。
2. リモート ホストのバックアップを作成する場合は、[別のコンピュータへ接続] を選択して、Hyper-V ホストを指定します。
3. [バックアップ (1 回限り)] または [バックアップ スケジュール] のどちらかを選択します。
4. [バックアップの構成の選択] ページで、[サーバー全体] または [カスタム] を選択します。[カスタム] を選択した場合は、バックアップを作成する VM に関連したデータを含む全ボリュームを指定する必要があります (これには、VM 構成データ、仮想ディスク、スナップショットが含まれます)。
5. バックアップの保存先を選択します。
6. [VSS 完全バックアップ] または [VSS コピー バックアップ] のどちらかを選択します。VM のバックアップが実行されていないホスト ベースのバックアップでは、[VSS 完全バックアップ] を選択します。
7. 詳細を確認したら、[バックアップ] を選択します。

考慮事項

• VM に関連している全ボリュームのバックアップを作成する必要があります。これには、仮想ハード ディスク (VHD)、VM 構成ファイル、およびスナップショットが含まれます。
• バックアップ スケジュールを作成している場合は、WSB 専用にフォーマットして使用する専用のローカル ボリュームを使用する必要があります。1 回限りのバックアップを作成している場合は、非専用のローカル ボリューム、リムーバブル デバイス、またはネットワーク共有にバックアップを保存できます。
• バックアップ対象の VM に統合コンポーネントがインストールされていない場合、WSB では、バックアップ データの整合性を確保するために実行中の VM の状態が保存されます。
• バックアップが完了したら、バックアップ セットは、移植して、任意の Hyper-V ホストで使用できます。

WSB による VM の復元

WSB には個別のファイルを復元する機能が備わっていますが、この機能では VSS を使用しないため、バックアップ時に VM が実行されていると復元時に整合性が失われることがあります。実行中の VM を復元するには、ボリューム全体を復元する必要があります。

これを行うには、[スタート] ボタンをクリックし、[管理ツール] をクリックして、[Windows Server バックアップ] をクリックします。次に、[操作] ウィンドウで [回復] を選択します。データの復元元となるサーバー (WSB バックアップ データが保存されているサーバー) を選択し、復元元となるデータを選択します。この時点で回復の種類を選択します。

ここでは状況に応じてオプションを選択します。ホスト全体で障害が発生した場合など VM 全体 (VM 構成ファイル、スナップショット、仮想ディスクを含む) を復元する場合は、[Application Restore] (アプリケーションの復元) を選択して、[Hyper-V] を選択します (図 6 参照)。この場合は、個別のファイルを復元するオプションは表示されません。バックアップ セットに含まれているものすべてを復元する必要があります。この操作により、既存の Hyper-V やバックアップ以降に変更された VM 構成データが上書きされることはありません。

図 6 Hyper-V バックアップの復元 (画像をクリックすると拡大表示されます)

VHD だけが必要で、VM の構成データとスナップショットに問題がない場合は、[ファイルおよびフォルダ] を選択して、復元する VHD ファイルを選択できます。この処理では VSS ライタを使用しません。VM のバックアップは、このことを考慮して、VM の状態を保存した状態で、作成されている必要があります。

システム全体に及ぶ障害とデータ損失が発生し、Windows Server 2008 オペレーティング システムとそこで実行されている全 VM を含む Hyper-V ホスト自体を復元する必要がある場合は、Windows 回復環境を起動して、そこから復元を行う必要があります。このような復元は、Windows Server 2008 セットアップ ディスクまたは事前に構成されたディスク パーティションから実行できます。

Data Protection Manager

ここまでは、無料で使用できて安定性のある組み込みの WSB を使用して、Hyper-V ホストとゲストをバックアップおよび復元する手順と考慮事項を紹介しました。しかし、WSB は、企業レベルで使用するデータ保護ソリューションではありません。WSB が適していない場合は、Data Protection Manager (DPM) 2007 SP1 が適しています。現時点で 2008 年後半にリリースが予定されている DPM 2007 SP1 では、Hyper-V がサポートされ、次のような魅力的な機能が提供される予定です。

• すべての Hyper-V のホストとゲストに対応した単一の管理コンソール。
• VSS ベースのスナップショットをキャプチャする継続的なデータ保護 (最大 15 分間隔で、変更された部分のみのスナップショットをキャプチャします)。
• Hyper-V クラスタの認識。VM がクラスタ ノード間を移動してもバックアップで VM を追跡できます。
• DMP サーバーから DPM サーバーへのレプリケーション。
• ディスク メディアとテープ メディアのサポート (ディスク間、ディスクからテープ、D2D2T (Disk to Disk to Tape) のバックアップがサポートされます)。
• 全データに対応したバックアップと復元機能。対応データには、Hyper-V のホストとゲスト、実行中ゲストのエージェントレスな VSS のバックアップ、個別の VM の復元、フェールオーバー クラスタのデータ、SQL Server、Exchange Server、SharePoint、Hyper-V、Virtual Server など、そのクラスで最高レベルのアプリケーション固有の機能などがあります。
• バックアップ前およびバックアップ後のスクリプトによる処理。

現在、サードパーティ製のソリューションを使用している場合は、アプリケーションの更新プログラムに注意してみてください。多くのベンダでは、Hyper-V ホスト ベースのソリューションを市場に提供することに積極的に取り組んでいます。

スクリプトによるバックアップ

WSB には、WBadmin.exe という名前のコマンド ライン インターフェイスと、スクリプトで使用する一連の Windwos PowerShell コマンドレットが用意されています。これらを使用する際にも、ここまでに説明したバックアップの規則が適用され、レジストリを編集して Hyper-V の VSS ライタを手動で登録する必要があります。

図 7 に、WBAdmin で使用できるコマンドの一部を示します。WBAdmin の詳細については、go.microsoft.com/fwlink/?LinkId=124380 を参照してください。おわかりのように、WBAdmin には、バックアップ ポリシー自体を構成するものはありません。しかし、これらの設定は Windows PowerShell スナップインを使用して管理できます。このスナップインが登録されているかどうかは、次のコマンドを実行して確認できます。

Get-PSSnapin -Registered

次のコマンドを使用して、windows.serverBackup という名前のスナップインを読み込めます。

Add-PSSnapin windows.serverBackup 

このスナップインを読み込むと、WSB に対応した Windows PowerShell コマンドレット (図 8 参照) を使用できるようになります。各コマンドレットの詳しい説明を表示するには、次のコマンドを実行します。

Get-Command -PSSnapin windows.serverBackup | select name | get-help –full

Windows Server 2008 には、WSB 以外に、Hyper-V の VSS ライタを使用して、柔軟にスクリプトを作成するのに役立つ DiskShadow.exe という名前のユーティリティが用意されています。DiskShadow.exe を使用すると、シャドウ コピーを作成して、ドライブとしてマウントできるので、管理者は、WSB よりも選択的にバックアップを作成できます。DiskShadow では、Windows PowerShell パイプラインの入力が受け付られないので、DiskShadow にはスクリプト経由でコマンドを渡す必要があることを覚えておく必要があります。これには、次のようなスクリプトを使用します。

Delete Shadows Volume C:
Set Context Persistent
Begin Backup 
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow 
Create
End Backup
Expose %MyShadow% X: 
Exit

このスクリプトでは、まずドライブ C の既存のシャドウ コピーを削除し、その後、DiskShadow の実行後にもシャドウ コピーが存続できるようにしています。次に、トランザクション ブロックを作成して、なんらかのステップでエラーが発生すると、この処理自体がエラーになるようにしています。このブロックでは、DiskShadow は Hyper-V のライタが読み込まれていることと、ドライブ C がバックアップするドライブの一覧に追加されていることを確認します。

ドライブ C には、ドライブを識別するための GUID が割り当てられ、この GUID は MyShadow という名前の環境変数に格納されます。この処理が完了すると、シャドウ コピーが作成されます。

バックアップは、MyShadow 環境変数を使用して、ドライブ X として公開されます。ドライブ X 上にあるデータに対してはさまざまな処理を行えます。また、DiskShadow で「Unexpose X:」というコマンドを実行すると、ドライブ X を削除できます。

ただし、現時点では、DiskShadow を使用してバックアップを作成した Hyper-V VM の復元は手動で行う必要があります (VM を再度作成する必要があったり、スナップショットが維持されないなどの問題があります)。いくつかの明らかなデメリットがありますが、データは保護されます。

まとめ

DR は、一見すると終わりがない困難な作業になることがあります。しかし、サーバー仮想化は、テクノロジと低価格な導入コストという 2 つの面から新しい可能性をもたらしました。マイクロソフトは、仮想化だけではなく、エコシステムを提供します。サーバー仮想化プラットフォームと System Center ファミリ製品により、DR など、複雑化の一途を辿る組織が直面している難題に対応するより総合的なソリューションを提供します。

この記事の執筆にご協力いただいた James O'Neill 氏に感謝します。

Adam Fazio は、約 2 年前からマイクロソフト コンサルティング サービスに従事しており、現在は米国政府のとある事務所に駐在しています。IT 業界でのキャリアは 10 年以上で、Fortune 100 の企業でのさまざまなインフラストラクチャ プロジェクトやデータセンターの運用から、インターネットの開設まで、さまざまな事業に従事してきました。現在は、マイクロソフトが世界規模で展開している Virtual Rapid Deployment Program のテクニカル エスカレーション リードを務めています。