バックアップ、復元、および障害復旧について

  • [アーティクル]

 

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2010-11-01

Microsoft Exchange Server 2010では、高可用性とサイトの復元を実現するための新しい統一されたプラットフォームを提供しており、高い冗長性と可用性を備えたメールボックス データベースをすばやく容易に展開できます。ただし、冗長性とフォールト トレランスを最大限に高めたとしても、障害やエラーから完全に守ることはできません。Exchange 組織内の重要なデータに対して十分な保護対策をとることは、すべての組織で必要な運用タスクです。

データ保護計画の一環として、データの保護方法について理解し、どの方法が組織のニーズに最も適しているかを判断することが重要です。データ保護計画は、展開の計画段階で行う多くの決定に依存する複雑なプロセスです。

目次

サポートされているバックアップ テクノロジ

サーバーの回復

回復用データベース

データベースの移植性

ダイヤル トーンの移植性

Exchange ネイティブ データ保護

サポートされているバックアップ テクノロジ

Microsoft Exchange Server 2007 および Exchange Server 2003 には、データのバックアップと復元用に 2 つの異なるオプションがあります。Extensible Storage Engine (ESE) ストリーミング バックアップ API とボリューム シャドウ コピー サービス (VSS) バックアップ API のサポートです。Exchange 2010 では、ESE ストリーミング API はプログラム ファイルまたはデータのバックアップと復元に対してサポートされなくなりました。代わりに、Exchange 2010 では、VSS ベースのバックアップのみをサポートしています。

Exchange 2010 には、VSS ベースで Exchange のデータのバックアップを作成できる、Windows Server バックアップ用のプラグインが組み込まれています。Windows Server Backup を使用して、Exchange データベースのバックアップと復元を行うことができます。Exchange 2010 をバックアップおよび復元するには、Windows Server バックアップ (VSS プラグイン付き)、Microsoft System Center Data Protection Manager、サード パーティの Exchange 対応 VSS ベース アプリケーションなど、Exchange 2010 用の VSS ライターをサポートする、Exchange 対応アプリケーションを使用する必要があります。Exchange データのバックアップと復元に VSS を使用する場合は、以下の制限に注意する必要があります。

  • Exchange 2010 に付属の VSS プラグインを使用できるのは、アクティブ メールボックス データベース コピー、またはスタンドアロンの (レプリケートされていない) メールボックス データベースを含むボリュームのバックアップのみです。パッシブ メールボックス データベース コピーを含むボリュームのバックアップには使用できません。パッシブ メールボックス データベース コピーをバックアップするには、Microsoft System Center Data Protection Manager またはサード パーティの Exchange 対応 VSS ベース アプリケーションが必要です。

  • パッシブ メールボックス データベース コピーは、Microsoft Exchange レプリケーション サービス内の個別の VSS ライターを使用してバックアップします。Microsoft Exchange レプリケーション サービスの VSS ライターは、復元をサポートしません。パッシブ メールボックス データベース コピーは Microsoft System Center Data Protection Manager またはサード パーティの Exchange 対応 VSS ベース アプリケーションを使用してバックアップできますが、パッシブ メールボックス データベース コピーに対して VSS 復元を直接実行することはできません。ただし、VSS 復元をある別の場所に対して実行し、パッシブ コピーへのレプリケーションを中断した後、その別の場所から、ファイル システム内のパッシブ データベース コピーの場所に、データベースとログ ファイルをコピーできます。

Windows Server バックアップを使用して Exchange データをバックアップおよび復元する詳細な手順については、「Windows Server バックアップを使用した Exchange データのバックアップと復元」を参照してください。

ページのトップへ

サーバーの回復

メールボックス、クライアント アクセス、ハブ トランスポート、およびユニファイド メッセージング サーバーの役割の構成設定のほとんどが、Active Directory に格納されます。以前のバージョンの Exchange と同様、Exchange 2010 には失われたサーバーを復元するための Setup パラメーターがあります。このパラメーター /m:RecoverServer が、Active Directory に格納されている設定および構成情報を使用して、失われたサーバーを再構築および再作成するために使用されます。

失われた Exchange 2010 サーバーのサーバー回復を実行する詳細な手順については、「Exchange Server を回復する」を参照してください。データベース可用性グループに属している失われたサーバーを回復する詳細な手順については、「データベース可用性グループのメンバー サーバーを回復させる」を参照してください。

ページのトップへ

回復用データベース

回復用データベースは、以前のバージョンの Exchange にあった回復用ストレージ グループ (RSG) に代わる Exchange 2010 の機能です。回復用データベースは特別な種類のメールボックス データベースで、回復操作の一部として、復元されたメールボックス データベースをマウントし、復元されたデータベースからデータを抽出できます。restore-Mailbox コマンドレットを使用すると、回復用データベースからデータを抽出できます。抽出後、データをフォルダーにエクスポートしたり、既存のメールボックスに結合したりできます。回復用データベースを使用すると、現在のデータへのユーザー アクセスを妨げずに、データベースのバックアップやコピーからデータを回復できます。

回復用データベースを使用する前に、特定の要件を満たす必要があります。回復用データベースは、Exchange 2010 メールボックス データベースにのみ使用できます。以前のバージョンの Exchange のメールボックス データベースはサポートされません。また、データの結合と抽出に使用されるターゲット メールボックスは、回復用データベースにマウントされたデータベースと同じ Active Directory フォレスト内に存在する必要があります。

詳細については、「回復用データベース」を参照してください。回復用データベースを作成する詳細な手順については、「回復用データベースの作成」を参照してください。回復用データベースを使用する詳細な手順については、「回復用データベースを使用してデータを復元する」を参照してください。

ページのトップへ

データベースの移植性

データベースの移植性は、Exchange 2010 メールボックス データベースを同じ組織の他の Exchange 2010 メールボックス サーバーに移動またはマウントできる機能です。データベースの移植性を使用すると、回復プロセスでのいくつかのエラーの発生しやすい手動による手順をなくすことで、信頼性が強化されます。また、さまざまな障害のシナリオで、データベースの移植性によって回復時間全体が短縮されます。

詳細については、「データベースの移植性」を参照してください。データベースの移植性を使用する詳細な手順については、「データベースの移植性を使用して、メールボックス データベースを移動する」を参照してください。

ページのトップへ

ダイヤル トーンの移植性

ダイヤル トーンの移植性は、メールボックス データベース、サーバー、またはサイト全体に影響を与える障害に対し、制限付きのビジネス継続性ソリューションを提供する機能です。ダイヤル トーンの移植性によって、ユーザーは、自分のメールボックスが復元中または修復中の場合に、電子メールの送受信用に一時メールボックスを持つことができます。一時メールボックスは、同じ Exchange 2010 メールボックス サーバー上、または組織内の他の Exchange 2010 メールボックス サーバー上に配置できます。これにより、使用できなくなったサーバー上に存在していたユーザーのメールボックスを、代替サーバーでホストできるようになります。Microsoft Outlook 2010 または Office Outlook 2007 などの自動検出をサポートしているクライアントは、ユーザーのデスクトップ プロファイルを手動で更新する必要なしに、新しいサーバーに自動的にリダイレクトされます。ユーザーの元のメールボックス データが復元された後、管理者は、そのユーザーの復元されたメールボックスとダイヤル トーン メールボックスを 1 つの最新のメールボックスに結合できます。

ダイヤル トーンの移植性のプロセスは、ダイヤル トーン回復と呼ばれます。ダイヤル トーン回復を行うには、メールボックス サーバーに空のデータベースを作成し、エラーが発生したデータベースと置き換えます。ダイヤル トーン データベースと呼ばれるこの空のデータベースによって、エラーが発生したデータベースの回復中でもユーザーは電子メールの送受信が可能となります。エラーが発生したデータベースの回復後、ダイヤル トーン データベースと回復されたデータベースが交換され、ダイヤル トーン データベースのデータが回復されたデータベースに結合されます。

詳細については、「ダイヤル トーンの移植性」を参照してください。ダイヤル トーン回復を実行する詳細な手順については、「ダイヤル トーン回復を実行する」を参照してください。

ページのトップへ

Exchange ネイティブ データ保護

Exchange 2010 には、いくつかの新機能と革新的変更が含まれています。たとえば正しく展開および構成された状態でネイティブ データ保護機能を使用すると、従来のデータのバックアップが不要になります。Exchange 2010 に組み込まれている高可用性機能を使用して、障害の発生時にダウンタイムとデータ損失を最小限に抑えると、メッセージング システムの総保有コストも削減できます。組織では、これらの機能を法的情報保留などの他の組み込みの機能と組み合わせることで、従来の時刻を指定したバックアップへの依存度を低下または排除し、関連するコストを抑制できます。

Exchange 2010 によって従来の時刻を指定したバックアップから移行できるかどうかを判断すると共に、現在のバックアップ インフラストラクチャのコストを評価することもお勧めします。既存のバックアップ インフラストラクチャを使用して障害からの回復を試みる場合の、エンドユーザーのダウンタイムとデータ損失のコストを考慮してください。また、ハードウェア、インストール、ライセンスの各コスト、およびデータの回復とバックアップの維持に関連する管理コストも含めます。組織の要件によっては、少なくとも 3 つのメールボックス データベース コピーを使用する純粋な Exchange 2010 環境の総保有コストの方が、バックアップを使用する環境の総保有コストより少ない可能性があります。

バックアップは通常、次のシナリオに使用され、各ニーズに効率的に、費用対効果の高い方法で対応できる Exchange 2010 機能が存在します。

  • 障害回復   ハードウェアまたはソフトウェア障害のイベントでは、データベース可用性グループ (DAG) 内の複数のデータベース コピーにより、フェールオーバーがデータの損失なく短時間で行われるため、高可用性を実現できます。これにより、エンドユーザーのダウンタイムとそれに伴う生産性の低下 (すなわち従来の時刻を指定したディスクまたはテープへのバックアップからの回復にかかる大きなコスト) がなくなります。DAG を複数のサイトに拡張し、データセンターの障害からの復元に利用することもできます。

  • 誤って削除されたアイテムの回復   従来、ユーザーが削除したアイテムを後から回復する必要がある状況では、回復するデータが収録されたバックアップ メディアを探し、なんとか目的のアイテムを見つけて、ユーザーに渡す作業が発生しました。Exchange 2010 の新しい [回復可能なアイテム] フォルダーを使用し、フォルダーに保留ポリシーを適用すると、すべての削除済みデータと変更済みのデータを特定の期間、保持することができるため、アイテムをより簡単に回復できます。エンド ユーザーが誤って削除したアイテムを自分で回復できるようにすることで、1 つのアイテムの回復に関連する複雑さおよび管理コストが減少するため、Exchange 管理者や IT ヘルプ デスクの負担が軽減されます。詳細については、「メッセージングのポリシーと準拠」、「回復可能なアイテムについて」、および「保持タグおよびアイテム保持ポリシーについて」を参照してください。

  • データの長期保存   バックアップがアーカイブ目的で行われる場合もあり、通常、テープを使用して、ある特定時刻のデータのスナップショットを法令遵守の要件に従って、長期間保存します。Exchange 2010 の新しいアーカイブ機能、複数のメールボックスの検索機能、およびメッセージ保持機能により、エンド ユーザーがアクセス可能な方法で長期間、データを効率的に保存する機構が得られます。これを利用すると、コストのかかる、テープからの復元作業がなくなり、Microsoft Outlook や Outlook Web App などの豊富なクライアントが古いデータにアクセスできるようにすることで、エンド ユーザーの生産性が向上します。詳細については、「個人アーカイブについて」、「複数のメールボックスの検索について」、および「保持タグおよびアイテム保持ポリシーについて」を参照してください。

  • 特定時刻のデータベースのスナップショット   組織で、メールボックス データの過去の特定時刻のコピーが必要な場合は、Exchange の機能を使って DAG 環境で時間差コピーを作成できます。これは、DAG でデータベース全体をレプリケートする論理的な破損が発生し、過去の時点に戻る必要が生じた、稀なイベントで有効です。管理者が誤ってメールボックスまたはユーザー データを削除した場合にも役立ちます。時間差コピーには、時間のかかるバックアップ サーバーから Exchange サーバーへのコピー処理が必要ないため、時間差コピーからの回復の方が、バックアップからの復元より速い可能性があります。エンド ユーザー ダウンタイムを短縮することで、総所有コストを大幅に削減できます。

バックアップなしのログの切り詰め

正常に実行された完全または増分バックアップの最後に実行される機能の 1 つが、データベース回復で不要になったトランザクション ログ ファイルの切り詰めです。バックアップが実行されていない場合は、ログの切り詰めは発生しません。ログ ファイルの作成を防ぐには、レプリケーション データベースの循環ログを有効にします。循環ログと連続レプリケーションを組み合わせると、ESE 循環ログとは異なる、連続レプリケーション循環ログ (CRCL) と呼ばれる新しい種類の循環ログが得られます。ESE 循環ログが Microsoft Exchange Information Store サービスによって実行および管理されるのに対して、CRCL は Microsoft Exchange Replication Service によって実行および管理されます。ESE 循環ログを有効にすると、追加のログ ファイルが生成されることはなく、必要に応じて現在のログ ファイルが上書きされます。ただし、連続レプリケーション環境では、ログの配布や再生用にログ ファイルが必要です。その結果、CRCL を有効にすると、現在のログ ファイルは上書きされず、ログの配布や再生処理用に閉じられたログ ファイルが生成されます。

具体的には、Microsoft Exchange Replication Service ではログの連続性を維持するように CRCL が管理されるため、レプリケーションに必要なログが削除されることはありません。Microsoft Exchange Replication Service と Microsoft Exchange Information Store サービスは、どのログ ファイルを削除できるかに関してリモート プロシージャ コール (RPC) を使用して通信します。

高可用性 (時間差なし) メールボックス データベース コピーで切り詰めが発生する場合、次の質問の答えは "はい" でなければなりません。

  • ログ ファイルがバックアップされていますか、または CRCL が有効になっていますか。

  • ログ ファイルがチェックポイント未満ですか。

  • データベースの他の時間差なしコピーは、削除に同意しますか。

  • ログ ファイルはデータベースのすべての時間差コピーによって検査されていますか。

時間差データベース コピーで切り詰めが発生する場合、次の質問の答えは "はい" でなければなりません。

  • ログ ファイルがチェックポイント未満ですか。

  • ログファイルは ReplayLagTime + TruncationLagTime より古いですか。

  • ログ ファイルがデータベースのアクティブ コピーで削除されていますか。

循環ログを有効または無効にする方法については、「メールボックス データベースのプロパティの構成」を参照してください。

Exchange のネイティブ データ保護を実装する際の考慮事項

Exchange 2010 に組み込まれた機能を従来のバックアップの置き換えとして使用するには、いくつかの技術的な根拠や問題を考慮する必要があります。次の一覧で、こうした考慮事項の一部を紹介します。特別な考慮事項や組織に固有の考慮事項も存在する可能性があります。次の問題を考慮してください。

  • どれだけの数のデータベースのコピーが展開されるか。RAID など、従来の形式のデータベース保護、または従来の VSS ベース バックアップをやめる前に、少なくとも 3 つのメールボックス データベースの (時間差なし) コピーを展開することを強くお勧めします。

  • 目標回復時間と目標回復ポイントを明確に定義し、従来のバックアップの代わりに内蔵機能の組み合わせを使用すると、これらの目標を達成できることを立証する必要があります。

  • システムで保護対策を講じた障害に対して、さまざまな障害シナリオをカバーするために各データベースのコピーがどれだけ必要かを決定する必要があります。

  • DAG またはその一部のメンバーの使用をとりやめる場合、それによって従来のバックアップ ソリューションをサポートするための十分なコストが得られますか。その場合、そのソリューションにより、目標回復時間または目標回復ポイントのサービス レベル契約 (SLA) が向上しますか。

  • コピーをホストしている DAG メンバーで、コピーまたはコピーの整合性に影響する障害が発生した場合、特定時刻のコピーを失っても対処できますか。

  • Exchange 2010 を使用すると、より大きなメールボックスを展開できます。メールボックス データベースの推奨最大サイズは、Exchange 2007 の 200 ギガバイト (GB) から 2 テラバイトに増加しています (高可用性メールボックス データベース コピーを 2 つ以上使用している場合)。ほとんどの組織が展開しそうな、より大きなメールボックスに基づいて、データベース コピーまたは時間差データベース コピーをアクティブにするときに大量のログ ファイルの再生を必要とする場合の目標回復ポイントは何ですか。

  • アクティブ データベース コピーでの論理的破損をどのように検出し、データベースのパッシブ コピーへのレプリケートをどう防ぎますか。この状況に対する回復計画は何ですか。このシナリオは過去にどれくらいの頻度で発生しましたか。論理的破損が組織で頻繁に発生する場合、そのシナリオを設計に取り込むことをお勧めします。それには、1 つ以上の時間差コピーを十分な再生の時間差があるウィンドウで使用し、論理的破損が発生したときに、他のデータベース コピーに破損がレプリケートされる前に検出して対応できるようにします。

ページのトップへ

 © 2010 Microsoft Corporation.All rights reserved.