バックアップで満足せずリカバリまで考える：Windows Server環境バックアップ実践 [リカバリ編]（4/5 ページ）

[谷川耕一，ITmedia]

System RecoveryはサーバのCPUリソースを消費する

画面4：パフォーマンス最大時のCPUリソースの消費状況（画像クリックで拡大）

　Backup Exec System Recovery 8で、データのバックアップも兼ねられると述べたが、これはお勧めではない。ディスク丸ごとコピーという方法は、コピー時にサーバのCPUリソースをかなり消費する。頻繁にコピーを行うと、サーバのパフォーマンスに大きく影響を及ぼす可能性があるのだ。

　設定でバックアップのパフォーマンスを調整できる。これを最大にすると当然ながらバックアップは早く終わるが、サーバのCPUリソースを大きく消費する。逆にパフォーマンスを低くすれば、時間はかかるがCPUリソースの消費は減る。ちなみに我が社のDC2というサーバのCドライブとDドライブをバックアップした際、パフォーマンス最大の設定で約260分、最小では780分、つまり約13時間もかかった。これでは頻繁にコピーを取ることはできない。

　理想的にはサーバの起動ディスクは、Backup Exec System Recovery 8で保護する。このスケジュールはシステムに影響を及ぼさない最低限の範囲で行うようにする。データには、サーバ処理に影響が少ないBackup Exec 12で、できるだけ頻度高く バックアップを行う構成がいいだろう。なるべくならば、起動ディスクにはバックアップ対象となる重要データは置かず、別のディスクを用意したほうが効率はいい。

　ちなみに、Backup Exec System Recovery 8の2回目以降の増分リカバリポイントの作成は更新が少なければかなり高速だ。上記のDC2の場合も、ほんの数分で終了する。

異なるスペックのマシンへのリカバリ

　バックアップしたディスクイメージは、まさにディスクとして認識できる。Windowsのエクスプローラから表示できるドライブ文字を、リカバリポイントに割り当てることで、リカバリポイント内のファイルが検索できるようになる。Recovery Point Browserというツールを使えば、リカバリポイント内のファイルを開くことも可能だ。これらの機能を用い、必要なフォルダやファイル単位でも復旧することは可能だ。

　サーバ全体を復旧する方法としては、USBのハードディスクなりにリカバリポイントをコピーし、それを新しいマシンに適用するのが簡単だ。新しいマシンをBackup Exec System RecoveryのCDを用いて起動し、「ホーム」パネルで、「コンピュータを修復」をクリックする。リカバリポイントの入っているUSBハードディスクが認識されリカバリポイントが表示されるので、それを選択し復旧対象のディスクを指定すれば、あとはほぼ自動的に復旧が行われる。

　異なるハードウェアには、Restore Anywareという機能を使うこと復旧できる。この場合、新しいマシンのドライバディスクやWindows OSのCDなどは、あらかじめ用意しておく必要がある。上記と同じ手順で復旧先のディスクを選んだあと、「Restore Anyware を使用（別のハードウェアに復元する場合）」にチェックマークを付け、あとはウィザードの指示に従いCDを入れ替えるなどの処理をするだけだ。

　また、リカバリポイントから仮想ディスク形式への変換も可能だ。これを行えば、起動イメージを仮想マシンで動かすことができる。こちらについては実際に試してはいないが、マニュアルの記述を見るとVMware GSX Server 3.1および3.2、VMware Server 1.0、VMware ESX Server 2.5および3.0、 VMware Infrastructure 3、Microsoft Virtual Server 2005 R2などで動かせるようだ。