どうやってリカバリするのか？
仮想化環境に限った話ではないが、データ保護戦略を立案するには、先行してバックアップを考慮するのではなく、どのような要件のもとにリカバリするのか、許容される時間やシステム的な影響はどう考慮するのか、が重要になってくる。
物理環境で当たり前とされてきた手法の一部は、サーバ仮想化のアーキテクチャにより変更されたものがある一方で、ビジネス要件から見たバックアップやリカバリ要件の定義には本質的に変わらないものも少なくない。まずは、適用システムから見る特性について整理してみよう。
図1：利用フェーズから見るリカバリ要件
※クリックすると拡大画像が見られます
（1）テスト／開発環境
仮想化が利用された初期段階では、テスト／開発環境を目的としたケースも見受けられ、こういったケースでは、初期状態に戻すことがゴールであったり、時間的制約も「物理環境をスクラッチから作るより短時間なら便利」ということもあったりするだろう。このような環境では、仮想マシン全体をリセットするイメージファイル単位でのリカバリが最適だろう。
（2）部門システム
次に、一部の部門サーバの仮想化では、エンドユーザーへのサービス提供という要件も加わり、若干要件が厳しくなる。代表的な例として、ファイルサーバやメールサーバなどを思い描いていただけると理解しやすいかもしれない。
イメージ単位で仮想マシン全体を戻してしまうことが望ましい場合もあるが、ファイルやディレクトリ単位、あるいは個別のメールなどだけを戻したいというケースも想定される。つまり、システムとしては健全に動作しているものの、特定のオブジェクトを戻したいというケースだ。テストや開発環境とは異なり、実際の運用に入っているからこそのニーズといえるだろう。実際の運用フェーズに入ると、仮想マシン全体をイメージファイルからリストアして、全体リカバリを行うケースは少なくなるのが一般的だ。
（3）基幹システム
企業の基幹システムになると、部門サーバでの利用形態に加え、単一の仮想マシンだけではなく、複数の仮想マシンが相互関係を持つもの、あるいはデータベースのトランザクションの関連性を含めたリカバリなど、要求されるシナリオも多岐に渡る。これらのシナリオに対応できるようなリカバリ戦略だけではなく、バックアップ戦略も立案する必要がある。
（4）クラウドコンピューティング環境
プライベートクラウドとして企業内へのサービス提供を行っているIT部門やパブリッククラウドを提供するASP/IaaSベンダーになると、規模や利用形態も大きく異なる。サーバ仮想化プラットフォームを利用して、利用者（ユーザー部門／外部ユーザー）が仮想マシンを構築、利用するケースだ。利用者サイドでは、データの投入などを経てシステム利用を行うのが一般的であり、このような環境においても、データ保護のニーズは当然ながら存在する。
