バックアッププロセスの最適解は運用から考えろ！：仮想化環境のデータバックアップ 最適解の見つけ方（2）（2/3 ページ）

各運用スタイルに適したバックアップ手法

　続いて、これらの運用スタイルごとに、適するバックアップ手法を紹介する。

（1）統合バックアップ型に適した手法

　統合バックアップ型の運用スタイルでは、特定のデータ管理者が、さまざまなタイプのデータ保護に責任を持つことになるため、単一のユーザーインターフェースで、かつ、豊富なアプリケーションサポートが可能な「バックアップエージェント型」が最も適している。シマンテックのNetBackupや、クエストソフトウェアのNetVaultが代表的なツールだろう。

　仮想化されたサーバのシステム領域については、仮想連携の機能であるVADP（vStorage API for Data Protection）を利用するが、データ保護のベースはバックアップエージェントを利用することに重きを置く。

（2）仮想基盤型に適した手法

　仮想基盤型の運用スタイルでは、「システムの保護」という観点と、「アプリケーションデータの保護」という観点を分けて考える必要がある。するとシステムの保護は仮想基盤の管理者が責任を持つ範囲となるので、仮想基盤管理者の視点で、仮想環境のコンソールとの統合性が優れているツールが望ましい。「ストレージ機能連携型バックアップ」であれば、EMCのAppSyncやNetAppのVirtualStorageConsole（VSC）が、vSphereクライアントへのPlug-in統合がされている代表的なツール例だ。「仮想機能連携型バックアップ」では、シマンテックのBackup Exec 2012が仮想コンソールとの統合を提供している例となる。

　一方、アプリケーションデータの保護では、各アプリケーションシステムの管理者が実施するため、アプリケーション固有のバックアップツールを利用すればよい。例えば、Oracle Recovery Manager（RMAN）、DB2 backup and restore、Informix backup and restore、Sybase Backupなどのアプリケーション標準バックアップ機能を利用したり、長年利用し慣れたバックアップツールや手法でアプリケーション管理者がバックアップするイメージだ。

図4　仮想基盤型と統合バックアップ型を比較したメリット・デメリット

（3）セルフマネジメント型に適した手法

　セルフマネジメント型の運用スタイルでは、各アプリケーションシステム管理者が実施する前提であるため、仮想環境のコンソールとの統合というよりも、シンプルで直感的なGUIインターフェースの方が望ましい。

　シンプルで直感的なGUIインターフェースで、かつセルフマネジメントも可能なツールとしては、vSphere5.1からリニューアルされたVMware vSphere Data Protection （VDP）が例として挙げられる。このツールでは、仮想マシン内の個別ファイルや、フォルダまたはディレクトリをリストアすることもできる。さらに、ファイルレベルのリストアについては、vSphere Data Protection Restore ClientというWebベースのツールを使用して実行する。これにより、管理者に依頼することなく、アプリケーション担当者自身でリストアを実行できる。

　以上、3つの運用スタイルとそれに適した手法を紹介してきた。現状の運用スタイルは、「統合バックアップ型運用スタイル」か「仮想基盤型運用スタイル」が主流であろう。今後、企業・団体において、仮想環境の採用がさらに拡大する中で、セルフマネジメント型運用スタイルに応じたバックアップ需要も増してくるだろう。

　以下、本稿では、現在の主流である「仮想基盤型運用スタイル」に焦点を絞りながら、ベストなバックアップ手法の選び方を検討していく。

仮想基盤型運用スタイルにおける最適なバックアップ手法の選び方

（1）「RTO（リカバリ時点）、RPO（リカバリ時間）」の視点

　まずは、「仮想基盤型運用スタイル」でのシステムバックアップにおいて、「仮想機能連携型バックアップ」と「ストレージ機能連携型バックアップ」のどちらを利用すればよいだろうか。

　RPOという観点では、「ストレージ機能連携型バックアップ」が数分レベルのSLAも可能であることに対し、「仮想機能連携型バックアップ」は1日というSLAが基本となる。ここでの選定ポイントは、システムのソフトウェア障害に対して、「1日前のシステム状態に戻したい」という一般的な需要のみを考慮するのか、「数分前のシステム状態に戻したい」というさらに踏み込んだ需要まで考慮するかどうかだ。多くのケースでは、1日前のシステム状態に戻れば許容されるだろう。

　一方、RTOという観点では、「ストレージ機能連携型バックアップ」も「仮想機能連携型バックアップ」も大差ないといえる。CBT（Change Block Tracking）リストアが適用できるリストアオペレーションでは、例えば100GBほどの仮想マシンでもブロック差分量が300MBぐらいであれば、1分程度のリカバリ時間を実現できるためだ。

（2）「災害対策」という、もう1つの重要な視点

　ここでもう1つ、「災害対策」という重要な視点もお伝えしたい。従来の物理環境での災害対策では、専用のハードウェアやバックアップサイトの常時メンテナンスが必要であり、復旧手順も複雑で、実際の切り替え時にはRTOが長期化する可能性があった。

　一方、仮想化環境では、物理環境と比べて災害対策のコストが下がることや復旧手順が簡単になることから、実装のしきいがぐっと下がってきている。具体的には、本番サイトと同一のスタンバイサーバは不要であることや、異なるハードウェア上に複数のシステムを統合できたり、古くなったサーバをバックアップサイトで再利用できるといったことが挙げられる。

　以上のことから、従来の重要度の極めて高いシステムのみを物理環境で災害対策していた形態から、仮想技術を利用した共通基盤を活用した、システムの重要度に応じた災害対策インフラを構築できる形態が実現している。

　仮想化環境を活用した災害対策インフラを実装する上では、可用性や信頼性からストレージ機能との連携は切っても切り離せない。

　そこで、災害対策まで視野に入れるのであれば、「ストレージ機能連携型」を選択しておいた方が、災害対策とバックアップの住み分けが実装しやすくなる。例えば、下図の例ならば、災害対策された仮想サーバのフェイルオーバはVMware vCenter Site Recovery Managerを利用して仮想基盤管理者が実施するが、データの整合性が問われるデータベースアプリケーション個別のデータからのリストアはアプリケーション担当者が実施する、という役割分担を透過的に実現しやすいといえる。

図5　仮想サーバのフェイルオーバ実行イメージ

　また、従来はデータ保護のSLAを考える上で、ディスクの多重障害やバックプレーン障害などの極めてレアなケースを考慮するかどうかという点は、悩ましい判断ポイントであった。しかし、災害対策構成が取られている環境であれば、ディスクの多重障害やバックプレーン障害は災害対策に含まれる形で考えることが可能になる。

図6　データ保護のSLA