そこでRTO（Recovery Time Objective：目標復旧時間）がそこまで短くなくてもいいという企業のために、DRサイトに仮想マシンを立て、そこに本番サイトのバックアップサーバからレプリケーションによって複製を取り、万一の障害発生時にはDRサイトの仮想マシンを稼働させる「バーチャルスタンバイ」という機能を提供しているベンダーがある。

　実際の動作としては、バックアップ状況をバーチャルスタンバイ機能が常にモニタリングしており、バックアップが行われたタイミングでDRサイトの仮想マシン上にも複製を作り、何かトラブルが起こったときには、自動で仮想マシン上のバックアップデータを利用可能な状態にしてくれる。これによってユーザーは万一のときにも、DRサイトにアクセスすれば、ある一定時間前と同じシステムとデータを使うことが可能となる。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図4 DRサイトの仮想マシンを活用したバックアップの動作例（出典：日本CA）

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図5 DRサイトの仮想マシンを活用した復旧の動作例（出典：日本CA）

仮想化環境と連携してバックアップできるか

　そもそもの話だが、上で紹介した2パターンの混在環境のバックアップ方法のうち、1つ目の物理サーバ上の仮想マシンの構成が変わらない場合には、この項目は特に意識する必要はない。物理サーバ内に仮想マシンが存在していても、バックアップツールは従来通り、物理サーバだけを見ていればいいからだ。

　しかし、2つ目の仮想環境が増えたり、移行したりする場合には、バックアップツールが仮想環境をきちんと認識できなければならない。

　自社がどちらの構成の混在環境をバックアップしたいのかで、バックアップツールが仮想化環境と連携する必要があるかどうかも違ってくる。

物理環境と仮想環境を同じ操作性でバックアップできるか

　この項目はつまり、直感的で使いやすく、操作もシンプルなユーザーインタフェースが提供されているかどうかということだ。また、物理環境と仮想環境を1つの統合コンソールで一元的に管理できるかも、管理者の業務効率を考える上では非常に大きなポイントだ。

　実際に生のユーザーの声として、幾つもの管理画面を開いて、あちこちのステータスを見たくないという要望は本当に多いという。確かに朝会社に来て、ジョブが終わったかどうかをチェックするときに物理サーバごとに管理画面を立ち上げなければならないというのでは、管理者のモチベーションも大きく低下するだろう。

　物理／仮想混在環境がかなり普及してきた現在でも、2つの環境を全く同じ操作性で管理できないバックアップツールはまだあり、さらに1つのツールでも、物理は物理、仮想は仮想でしか管理できない製品もあれば、LinuxとWindowsといったOSの違いによって管理画面が異なる製品もあるという。製品選定時には、十分に留意すべき点だ。

仮想マシンが増えたときのバックアップ時間は問題ないか

　これまでのように物理サーバとテープ装置間を直結したバックアップ方法なら、バックアップ時間はそれほど気にならなかったかもしれないが、社内ネットワーク上にバックアップサーバを置いて混在環境のバックアップを行うという場合には、上でも述べたようにLANを経由するバックアップ方法では多大な時間を要する可能性がある。

　バックアップ時間の短縮を図りたいのであれば、LANとは別のネットワークを経由してバックアップを行うシステム構成を採る必要があるだろう。

　また最近では、仮想マシンを構築する物理サーバには必要以上の負荷をかけたくないという企業のニーズも高まっており、「エージェントレスで動作するバックアップツール」というのも、選定基準の1つの挙げられることが多いようだ。

仮想マシンの数によってライセンスフィーが高額にならないか

　ビジネス側の変化に柔軟に対応できるシステム環境を実現するためには、物理サーバ上の仮想マシンを状況に応じて、増やしていく必要がある。しかし、例えばバックアップツールのライセンスフィーが仮想マシン単位に発生するというのでは、管理者は自由に仮想環境を追加していくこともままならないだろう。

　現在提供されている製品の中には、ハイパーバイザー単位でのライセンスフィーを設定しているものがあり、これならハイパーバイザー上で仮想マシンがどれだけ増えても、追加のライセンスフィーは一切発生しない。製品選定時には、コスト面からも将来のバックアップ対象を考慮した拡張性をチェックしておく必要がある。