Exchange Server 2007のシステムを設計する際には，障害が発生した場合に備えて，システムを回復させる戦略を策定しておこう。局所的な障害からサイト全体に及ぶ大規模な災害まで想定しておくことが望ましい。
Exchange Server 2007に起きうる障害としては，障害の程度の「小さい」ものから順に，以下のものが考えられるだろう。
- メール・アイテムまたはメール・ボックスの損失
- データベースまたはストレージ・グループの損失
- サーバー（メール・ボックス・サーバー，ハブ・トランスポート・サーバーなど各役割（ロール））の障害
- サイト全体または組織全体に及ぶ障害
そこで，それぞれの障害を想定した復旧計画を設計することになる。その際は，必ず業務への影響範囲と損失を考慮する。その上で，復旧時間の目標値を定めて，必要な手段をドキュメント化しておくことをお勧めする。
Exchangeの内蔵機能で復旧を図る場合
例えば，メール・アイテムやメール・ボックスの損失に対しては，Exchangeの機能である「削除済みアイテム」「削除済みメール・ボックス」の機能を使用した手順をドキュメント化しておこう。データベースやストレージ・グループの障害に対しては，同じくExchangeの機能である「回復用ストレージ・グループ」の機能を使用した回復手順を策定しておくとよい。
「回復用ストレージ・グループ」の機能を使用すると，単一のメール・ボックスやデータベースなどを回復する必要がある場合に，運用環境にあるデータベースの代替コピーからデータを抽出して，既存のメール・ボックスに結合したりできる。「回復ストレージ・グループ」は，特殊な管理用ストレージ・グループであり，MAPI以外のプロトコルが無効になっているなどの制限がある。詳細は，マイクロソフトの技術資料「回復用ストレージ グループを使用してメール・ボックスを回復する方法」を参照していただきたい。
「回復用ストレージ・グループ」を使用して回復できるのは，メール・ボックスのデータベースのみである。パブリック・フォルダの障害対策を行うのであれば，データを複数のサーバーに複製するか，バックアップ・ソフトウエアなどを使用してアーカイブしておくしかない。また，パブリック・フォルダを複数のサーバーに複製する場合は，Exchange内蔵のクラスタ機能である「クラスタ連続レプリケーション」の機能は利用できないのでご注意いただきたい。
バックアップ・データから復旧を図る場合
次にストレージ・システムを含むサーバー全体に障害が発生した場合を想定して，「バックアップ方法と回復手順」をドキュメント化しておきたい。ここでは，バックアップとリストアに関する考慮点を上げておこう。
・データベースのバックアップ
Exchange Serverのデータベースをバックアップする方法は，Exchange Serverの運用を停止せずにオンラインで行う方法（オンライン・バックアップ）と，一時的に運用を停止させてデータベースをバックアップする方法（オフライン・バックアップ）の2つに大別される。
Exchange 5.5以前のバージョンが使用されていた当時は，メール・ボックスの平均サイズが50Mバイト以下と比較的小さく，データベースの容量も10Gバイト前後であった。そのため，SCSIケーブルで接続されたテープ装置にオンライン・バックアップすることが主流であった。
しかし，現在のようにメール・ボックスの平均サイズが100Mバイトを超え，一台のサーバーで数千のメール・ボックスをサポートするようになると，以下の点を考慮する必要性が出てきた。
- バックアップ時のサーバーへ負荷（CPU，ディスクI/Oなど）
- バックアップ・ウインドウ（バックアップにかかる時間）とデータベース保守の時間枠
- データの回復時点（いつの時点まで回復可能か）の設定
- 回復に要する時間
最近は，バックアップ専用サーバーを設けて，本番運用とは独立したLANを使用して，オンライン・バックアップする方法がとられることが多くなった。また，リストアに要する時間を短縮するため，ディスクへバックアップすることも多く見受けられる。
例えば，シマンテックの「Backup Exec」（11dでExchange Server 2007に対応した）などのサード・パーティ製品や，Windows Server 2003のバックアップ・ユーティリティを使って，まずハードディスクにデータをバックアップする（これを一次バックアップと呼ぶ）。その後，バックアップ専用サーバーを使って，一次バックアップのデータをテープ装置にバックアップする（これを二次バックアップと呼ぶ）方法がとられている。
一次バックアップをハードディスクに保存するのは，ハードディスクを使った方がバックアップやリストアにかかる時間が短縮できるからである。特に，リストアにかかる時間の短縮は，業務を止めない上で重要になる。その一方で，データを遠隔地（オフサイト）に保存したり，長期間に渡って保存（アーカイブ）したりする用途には，テープが向いている。二次バックアップをテープに保存して遠隔地に保存すれば，サイトそのものに障害が発生したような場合に備えられる。
データベースの容量が大きい場合は，複数のテープ・メディアにバックアップ・データを分割することになる。そのため，テープの世代管理を含めたバックアップ・ジョブの設計が重要となる。
・ストレージ・システムが備えるバックアップ機能
Exchange Serverを24時間稼働する必要がある環境では，オンライン・バックアップ中であってもサーバーのパフォーマンスを低下させたくないという要件が求められる。こうした場合，Windows Server 2003から導入された「ボリューム・シャドウ・コピー・サービス（VSS）」とSANストレージ・システムが備えるスナップショット機能（例えば日本ヒューレット・パッカードの「EVAストレージ」では，「Business Copy」と呼ぶ機能）を組み合わせて，バックアップを取得する方法がとられる。
この方法では，Exchange Serverのサービスは停止せず，VSS機能によって書き込みが停止した状態で，ストレージ・システムの筐体内にディスク・ボリュームのコピーが作成される。その後に筐体内のコピーをバックアップするため，運用中のサーバーに影響を与えない特徴がある。
ただし，この方法でコピー（オフライン・バックアップ）されたデータベースについては，必ずデータベースの整合性のチェック（第3回で紹介した「Exchange Serverデータベース・ユーティリティ（Eseutil.exe）」を使って「Eseutil /K」と実行する）を行うようにMicrosoftが強く推奨している。
SANストレージ・システムのハードウエアが備えるスナップショット機能を利用すると，非常に短時間で，システムを止めずにバックアップやリストアが実行できる。なお，スナップショット機能を利用したバックアップの仕組みや運用については，ITproの既存記事「管理者の夢をかなえる新世代ディスク・バックアップ，パート3：価格が大幅に低下したストレージ装置のスナップショット」を参考にしていただきたい。
・パフォーマンス
バックアップ・ウインドウとデータベース保守の時間枠を設計する場合，バックアップの時間帯と「データベースの保守の時間帯（図4-1）」が重ならないようにバックアップ ジョブを考慮する必要がある。
 |
| 図4-1：データベースの「保守のスケジュール」プロパティ |
「データベースの保守の時間帯」には，データベースの整合性のチェックとページの配置の最適化が行われる。この時間帯に，オンライン・バックアップが実行されると，そのタスクが停止する仕様になっている。そのため，データベースの最適化が正常終了するように，それぞれに要する時間を予測して時間枠を設計する。なお，データベースのサイズが増加するにつれて，データベースの保守とバックアップにかかる時間も長くなる。時間枠の設定は，運用段階に入ってからも継続して見直す必要がある（図4-2，図4-3）。
 |
| 図4-2：オンライン保守の開始を示すイベント・ログの例 |
 |
| 図4-3：オンライン保守の完了を示すイベント・ログの例 |
・データ転送スループット
ローカル連続レプリケーション（LCR)またはクラスタ連続レプリケーション（CCR)の機能を使用している場合は，十分なデータ転送スループットを確保する必要がある。CCRでオンライン・バックアップを取得するためには，アクティブ側で実行する必要があるのでご注意いただきたい。
・データベースの復旧
データベースの復旧で考慮しておくべき点は，万一に備えて，定期的にリハーサルを実施しておくことである。その際に，テープ・メディアが正常に読み取れるかのチェックと，データのリストアにかかる時間を測定しておくとよい。また，バックアップのカタログ再構築に要する時間計測も重要である。
|
