Exchange Serverでのバックアップ、復元、ディザスター リカバリー

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

従来、次のシナリオにバックアップが使用されてきました。

  • ディザスター リカバリー: ハードウェアまたはソフトウェアの障害が発生した場合、DAG 内の複数のデータベース コピーを使用すると、高速フェールオーバーとデータ損失がほとんどまたはまったくない高可用性が実現されます。 これにより、ダウンタイムとそれに伴う生産性の低下 (すなわち従来の時刻を指定したディスクまたはテープへのバックアップからの回復にかかる大きなコスト) がなくなります。 DAG を複数のサイトに拡張し、ディスクやサーバー、ネットワーク、データセンターの障害からの復元に利用することもできます。

  • 誤って削除されたアイテムの回復: これまで、ユーザーが後で回復する必要があるアイテムを削除した状況では、回復する必要があるデータが格納されているバックアップ メディアを見つけ、何らかの方法で目的の項目を取得してユーザーに提供する必要があります。 Exchange 2016 と Exchange 2019 の [回復可能なアイテム] フォルダーと、それに適用できる保留ポリシーを使用すると、削除および変更されたすべてのデータを指定された期間保持できるため、これらのアイテムの回復が簡単かつ迅速になります。 エンド ユーザーが誤って削除したアイテムを自分で回復できるようにすることで、1 つのアイテムの回復に関連する複雑さおよび管理コストが減少するため、Exchange 管理者や IT ヘルプ デスクの負担が軽減されます。 詳細については、「Exchange Serverのメッセージング ポリシーとコンプライアンス」および「Exchange Serverでのデータ損失防止」を参照してください。

  • 長期データ ストレージ: バックアップはアーカイブとしても使用されており、通常はテープを使用して、コンプライアンス要件に従ってデータのポイントインタイム スナップショットを長期間保持します。 Exchange Serverの新しいアーカイブ、複数メールボックス検索、およびメッセージ保持機能は、エンド ユーザーがアクセス可能な方法でデータを長期間効率的に保持するメカニズムを提供します。 これにより、高価なテープからの復元がなくなり、生産性が高まります。 詳細については、「Exchange Serverでのインプレース アーカイブ」、Exchange Serverでのインプレース電子情報開示、Exchange Serverでのインプレースホールドと訴訟ホールドに関するページを参照してください。

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

これらの各シナリオを効率的かつコスト効率の高い方法で満たすネイティブのExchange Server機能があるため、環境内での従来のバックアップの使用を減らすか、または排除することができます。

Exchange ネイティブ データ保護

Exchange Server 2016 および Exchange Server 2019 の Microsoft が推奨するアーキテクチャは、Exchange Native Data Protection と呼ばれる概念を活用しています。 Exchangeネイティブ データ保護は、Exchange の組み込みの機能に依存して、バックアップを使わずにメールボックスのデータを保護します (これらの機能を使用してバックアップを作成することもできます)。 Exchange 2016 と Exchange 2019 には、正しく展開および構成された場合にネイティブ データ保護を提供できるいくつかの機能が含まれており、従来のデータバックアップを作成する必要がなくなります。 Exchange Serverに組み込まれている高可用性機能を使用して、障害発生時のダウンタイムとデータ損失を最小限に抑え、メッセージング システムの総所有コストを削減することもできます。 これらの機能を法的情報保留などの他の組み込みの機能と組み合わせることにより、従来の時刻を指定したバックアップの使用を減らしたり、なくすことで、関連コストを抑制できます。

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

従来のバックアップの代わりに、Exchange Serverに組み込まれている機能を使用する前に考慮する必要があるいくつかの問題があります。 組織に固有の考慮事項が存在する可能性もあります。 以下は考慮すべき問題の一例です。

  • 展開するデータベースのコピーの数を特定する必要があります。 RAID (Redundant Array of Independent Disks) や従来の VSS ベース バックアップのような、従来の形式のデータベース保護をやめる前に、少なくとも 3 つのメールボックス データベースの (時間差なし) コピーを展開することを強くお勧めします。

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

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

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

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

  • Exchange Serverでは、推奨される最大メールボックス データベース サイズが 2 テラバイト (2 つ以上の高可用性メールボックス データベース コピーが使用されている場合) を使用して、はるかに大きなメールボックスを展開できます。 ほとんどの組織がより大きなメールボックスを展開すると思われますが、データベース コピーまたは時間差データベース コピーをアクティブにするときに、大量のログ ファイルの再生を必要とする場合は、目標復旧時点を決定する必要があります。

  • アクティブなデータベース コピーの論理破損を検出して、データベースのパッシブ コピーにレプリケートしないようにする方法を決定する必要があります。 これには、この状況の復旧計画の決定と、過去にこのシナリオが発生した頻度が含まれます。 組織内で論理的な破損が頻繁に発生する場合は、1 つ以上の遅延コピーを使用して、そのシナリオを設計に組み込み、発生した場合に論理的な破損を検出して対処できるように十分な再生ラグ ウィンドウを使用することをお勧めします。その破損が他のデータベース コピーにレプリケートされる前に対処できます。

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

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

高可用性 (時間差なし) メールボックス データベース コピーで切り詰めが発生する場合は、以下を満たしている必要があります。

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

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

  • データベースの他の時間差なしコピーが削除に同意する。

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

時間差データベース コピーで切り詰めが発生する場合は、以下を満たしている必要があります。

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

  • ログ ファイルが ReplayLagTime + TruncationLagTime より古い。

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

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

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

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

VSS ライターのExchange Server

以前のバージョンの Exchange には、Microsoft Exchange Information Store サービス (store.exe) 内と Microsoft Exchange レプリケーション サービス (msexchangerepl.exe) 内の 2 つの VSS ライターが含まれていました。 Exchange 2013 に戻ると、Microsoft Exchange Information Store サービスで以前に見つかった VSS ライター機能が Microsoft Exchange レプリケーション サービスに移動されました。 このアーキテクチャは、Exchange 2016 と Exchange 2019 でも変わりません。 Microsoft Exchange ライターという名前のこのライターは、Exchange 対応 VSS ベースのアプリケーションによって、アクティブおよびパッシブ データベース コピーをバックアップし、バックアップされたデータベース コピーを復元するために使用されます。 ライターは Microsoft Exchange レプリケーション サービスで実行されますが、ライターをアドバタイズするには Microsoft Exchange Information Store サービスが実行されている必要があります。 そのため、Exchange データベースのバックアップの作成や復元には両方のサービスが必要です。

Exchange Server の回復

メールボックス サーバーとクライアント アクセス サービスの構成設定のほとんどすべてが Active Directory に格納されます。 以前のバージョンの Exchange と同様に、Exchange 2016 と Exchange 2019 には、紛失したサーバーを回復するためのセットアップ パラメーターが含まれています。 このパラメーター /m:RecoverServer は、Active Directory に格納されている設定と構成情報を使用して、失われたサーバーを再構築して再作成するために使用されます。 ただし、ローカルの web.config およびその他の構成ファイルなど、復元されていない複数の設定があることをご承知おきください。 さらに、カスタムのレジストリ エントリは復元されません。 信頼性の高い変更管理プロセスを使用してこれらの変更を追跡し、作成し直すことをお勧めします。

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

統一された連絡先ストアの回復

Microsoft Lync Server 2013 または Skype for Business Server 2015 が Exchange 2016 または Exchange 2019 環境で使用されている場合、ユーザーの Lync/Skype for Business連絡先情報は、ユーザーのメールボックス内の特別な連絡先フォルダーに格納されます。 このフォルダーを、統合連絡先ストア (UCS) と呼びます。 UCS 移行メールボックスを復元すると、ターゲット ユーザーのインスタント メッセージング連絡先一覧に影響が出る場合があります。 たとえば、前回のバックアップ後にユーザーが移行した場合、そのメールボックスを復元するとそのユーザーの連絡先一覧はすべて失われます。 それほど重大なケースではなくても、前回のバックアップ後に行われた連絡先一覧の変更は失われます。 このようなデータ損失をできるだけ防ぐため、メールボックスを復元する前に、インスタント メッセージング サーバーにユーザーのデータを戻しておいてください。

回復用データベース

回復用データベースは特別な種類のメールボックス データベースで、回復操作の一部として、復元されたメールボックス データベースをマウントし、復元されたデータベースからデータを抽出できます。 New-MailboxRestoreRequest コマンドレットを使用すると、回復用データベースからデータを抽出できます。 抽出後、データをフォルダーにエクスポートしたり、既存のメールボックスに結合したりできます。 回復用データベースを使用すると、現在のデータへのユーザー アクセスを妨げずに、データベースのバックアップやコピーからデータを回復できます。

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

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

データベースの移植性

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

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

ダイヤル トーンの移植性

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

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

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