仮想マシン単位のバックアップの課題：仮想サーバのバックアップをどうするか（3）（2/2 ページ）
サーバ仮想化では各仮想マシンをファイルとして扱える。これは障害の発生したシステムを復旧する場合に非常に便利だ。しかし、仮想マシンをファイルとしてバックアップすることにはいくつかのデメリットもある
仮想マシン・バックアップの実際
それではVMware ESXを例にとって、仮想マシン本体となるVMDKファイルのバックアップを取得する運用を考えてみよう。
VMware ESXはハイパーバイザ方式の仮想化技術なので、ホストOSが存在しない。しかし、インターフェイスとして動作するLinuxベースのESX Service ConsoleというOSから、仮想マシンそのものをファイルとして扱うことが可能である。
ESX Service Console上にインストールされたバックアップツールから、VMDKファイルをバックアップすると、オペレーティングシステムとデータの両方を含む仮想マシン全体をバックアップすることになる（および必要に応じてvmxなどのその他のファイル）。リストアの際には、やはりESX Service Console上で動作するバックアップツールを使いバックアップからリストアしたあと、適切なディレクトリにファイルを移動したりVMware ESX上にリストアした仮想マシンを登録したりといった作業になる。
仮想マシン単位のバックアップにおける問題点
この方法は、ゲストOS上でバックアップツールを動作させる方法と比較して、ディザスタリカバリにおいて圧倒的なメリットがある。しかし、以下のような問題点がある。
バックアップ対象を静的な状態にする必要がある
ゲストOSやその上で動作するアプリケーションが稼働中の状態では、対象となるVMDKファイルが常に更新されている状態となる。VMDKファイルは、仮想マシン上のデータのすべてを含む非常にサイズの大きい1つのファイルとなるので、バックアップの途中でこのファイルが変更される可能性があり、一貫性を保つことが困難である。整合性の取れていないファイルは、正常にリストアできないことになる。そのために、仮想マシンをバックアップのためにシャットダウンしたり、仮想マシンをエクスポートしたり、仮想マシンのスナップショットを作成するなどの方法を検討する必要がある。
増分・差分バックアップができない
VMDKファイルは1つのファイルとして扱われるため、少しでも変更があると全体がバックアップ対象となる。つまり、実際の運用では、毎回フルバックアップと同様の手順を実施するしかないのだ。リストアの場合も同様に、ゲストOS上ではひとつのファイルとして認識されるデータを戻したいだけだとしても、仮想マシン全体にあたるVMDKファイル自体をリストアするしか方法がない。
バックアップの負荷が環境全体に影響を与える
VMDKファイルは非常にサイズの大きいファイルとなるので、バックアップ処理の負荷が物理マシンに与える影響も大きくなる。また、複数のバックアップによる負荷が与えるESX Service Console自体への影響も考慮する必要がある。ホストOSでバックアップツールを動作させるのであれば、この問題が特に深刻となる。
仮想マシン単位でのバックアップは、ディザスタリカバリの目的には非常に適しているが、デメリットも多くあるため、日次でのバックアップに最適な手法とはいえない。少ない頻度で定期的に仮想マシン単位でのバックアップを行う運用が適しているといえる。この方法でバックアップを取った場合、システムのリカバリを行ったあとで最新のデータに戻るとは限らないが、データに関してはゲストOS上で行った日次バックアップからのリストアで補完することができる。
次回は、VMware ESXに固有のVMware Consolidated Backupについて解説する。
Copyright © ITmedia, Inc. All Rights Reserved.