Exchange 2007 のデータ バックアップとボリューム シャドウ コピー サービス

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2012-03-26

Windows Server 2008 のボリューム シャドウ コピー サービス (VSS) は、Microsoft Exchange Server 2007 をバックアップおよび復元するためにアプリケーションによって使用されます。VSS は、サード パーティのストレージ管理プログラム、ビジネス プログラム、およびハードウェア プロバイダがシャドウ コピーの作成や管理を組み込むことができるようにするインフラストラクチャを提供します。このインフラストラクチャに基づくソリューションでは、シャドウ (つまりミラー化された) コピーを使用して、Exchange 2007 データベースをバックアップおよび復元できます。

VSS は、リクエスタ (バックアップ アプリケーション)、ライタ (Exchange 2007 などの Windows 環境のアプリケーション)、およびプロバイダ (シャドウ コピーを作成するシステム コンポーネント、ソフトウェア コンポーネント、またはハードウェア コンポーネント) の間での通信を調整します。VSS を使用して Exchange 2007 をバックアップするには、バックアップ プログラムに Exchange 2007 対応の VSS リクエスタが含まれている必要があります。Windows Server 2008 に含まれている Windows Server バックアップ プログラムには、Exchange 対応の VSS リクエスタは含まれていません。

ただし、 Exchange 2007 Service Pack 2 には、Windows Server 2008 の Windows Server バックアップを使用して、ボリューム シャドウ コピー サービス (VSS) ベースで Exchange のデータのバックアップを作成できる、新しいプラグインが組み込まれています。Windows Server バックアップを使用すると、Exchange 2007 SP2 のデータベースのバックアップと復元を行うことができます。バックアップする必要があるアイテム、バックアップの格納場所、およびバックアップの復元方法について完全に理解することは、Exchange の管理者にとって重要なことです。Exchange 2007 でバックアップする必要があるアイテムの詳細については、「Windows Server バックアップを使用した Exchange データのバックアップと復元」を参照してください。

note注 :
また、Windows Server バックアップ プログラムは、Exchange 2007 Extensible Storage Engine ストリーミング API をサポートしていません。このプログラムを使用して、Exchange 2007 のストリーミング ESE バックアップを作成することはできません。

Exchange 対応の VSS バックアップは、アクティブ ストレージ グループとパッシブ ストレージ グループの両方についてサポートされます。Exchange パッシブ コピー バックアップ ソリューションは、VSS 専用のソリューションです。このソリューションは、レプリケーション サービスに含まれる Exchange Replica VSS Writer によって実装されます。ストリーミング バックアップは、アクティブ ストレージ グループからのみサポートされます。したがって、ストリーミング バックアップ API を使用してレプリカ データベースをバックアップすることはできません。レプリカ データベースをバックアップするには、VSS 対応のバックアップ プログラムを、Exchange Writer 用の VSS リクエスタと共に使用する必要があります。

note注 :
Exchange 2007 SP2 の Windows Server バックアップのプラグインでは、レプリケーション サービスに含まれる Exchange Replica VSS Writer はサポートされません。このため、このプラグインを使用してストレージ グループのパッシブ コピーをバックアップすることはできません。

Exchange 2007 では、同じ Exchange サーバーに対して、2 つの独立した VSS バックアップ操作の実行をサポートしています。また、Exchange 2007 Writer によって、Exchange データを別の場所に復元できます。これには、回復用ストレージ グループが含まれます。Exchange 2007 Writer を使用して、データベース ファイルを、ストレージ グループに関連付けられていないフォルダに復元することもできます。その後、JET データベース エンジンを使用してトランザクション ログ ファイルをデータベースに再生して、データベースを整合性があり、マウント可能な状態にすることができます。

note注 :
Microsoft Exchange Server 2003 では、ストリーミング バックアップ API を使用して、2 つの異なるストレージ グループに対して同時に 2 つのバックアップを実行できます。VSS を使用してこの操作を実行することはできません。Exchange 2003 では、VSS を使用した場合、最初のストレージ グループのバックアップが完了するまで、2 番目のストレージ グループをバックアップできます。また、Exchange 2003 Writer では、Exchange データを、元のパス以外のパスに復元できません。

Exchange 2007 に準拠するには、VSS ベースのバックアップ プログラムは次の基本的な要件を満たしている必要があります。

  • ファイルをバックアップするには Exchange Writer を使用する必要があります。
    Exchange 2007 には、Exchange ストアに組み込まれたライタが含まれています。
  • バックアップ プログラムはシャドウ コピー バックアップ セットを検証する必要があります。
  • ファイルを元の場所に復元する復元操作には、Exchange Writer を使用する必要があります。
    元の場所とは、VSS バックアップの作成元のサーバーと名前が同じである Exchange サーバーの同じファイル パスを指します。

これらの要件によって、シャドウ コピーによるバックアップの整合性と回復性が保証されます。これらの要件が満たされていない場合、マイクロソフト カスタマー サービス & サポート (CSS) では、バックアップ ソリューションが Exchange VSS フレームワークの外部で行われていると見なします。この場合、マイクロソフト CSS では、バックアップや復元の問題を解決できません。バックアップ ソリューション ベンダに問い合わせて、バックアップ プログラムがこのトピックに示されている要件を満たしていることを確認してください。これらの要件の詳細については、このトピックの「Exchange 2007 VSS の要件」を参照してください。

note注 :
サード パーティのバックアップ プログラムでは、プログラムのベンダがバックアップや復元の問題に対する最初のサポート窓口になります。マイクロソフト CSS では、Exchange データベースやトランザクション ログ ファイルで発生する可能性がある問題の診断や解決を支援することはできますが、ユーザーの Exchange 環境で利用可能なデータベース ファイルやトランザクション ログ ファイルの回復の支援は限定されています。

マイクロソフト CSS によって VSS ベースのソリューションがどのようにサポートされるかについては、マイクロソフト サポート技術情報の記事 841696「サードパーティ製ストレージ ソフトウェア ソリューションに対するマイクロソフトのサポート ポリシーの概要」を参照してください。

詳細情報

Exchange 2007 VSS の要件

ここでは、Exchange データベースの整合性と回復性を保証するためにシャドウ コピー バックアップ プログラムが満たしている必要がある Exchange 2007 の要件について説明します。ここでは、バックアップ プログラムが Exchange の要件を満たしているかどうかを示す具体的なアプリケーション イベントを示します。バックアップ プログラムおよび Exchange サーバーは、バックアップおよび復元プロセスに関連付けられた他のイベントをログに記録する場合があります。Exchange VSS の要件への準拠を検証するには、イベントがバックアップおよび復元操作中にログに記録されていることを確認してください。

現在、Exchange 上で実行されるサード パーティのバックアップ ソリューションについての認定プログラムはありません。VSS に準拠することによって、シャドウ コピーによるバックアップの整合性と回復性が保証されます。ただし、サード パーティのソリューションのパフォーマンスや信頼性は保証されません。

ファイルをバックアップするには Exchange Writer を使用する必要がある

Exchange データベース ファイル、トランザクション ログ ファイル、およびチェックポイント ファイルは、Exchange Writer によってのみバックアップされます。シャドウ コピー バックアップ時に Exchange Writer が使用された場合、以下のイベントがアプリケーション ログに記録されます。

イベントの種類 : 情報

イベント ソース : ESE

イベント カテゴリ : ShadowCopy

イベント ID : 2005

ユーザー : 該当なし

コンピュータ : ServerName.contoso.com

全般 : Information Store (2884) シャドウ コピー インスタンス 5 を開始しています。これは、backup-type シャドウ コピーとなります。

note注 :
このイベントで、backup type は実行しているバックアップの種類を表します。たとえば、backup type には、完全コピー増分差分があります。

イベントの種類 : 情報

イベント ソース : MSExchangeIS

イベント カテゴリ : Exchange VSS Writer

イベント ID : 9608

ユーザー : 該当なし

コンピュータ : ServerName.contoso.com

全般 : Exchange VSS Writer (インスタンス GUID) は、正常にスナップショットの準備をしました。

イベントの種類 : 情報

イベント ソース : MSExchangeIS

イベント カテゴリ : Exchange VSS Writer

イベント ID : 9610

ユーザー : 該当なし

コンピュータ : ServerName.contoso.com

全般 : Exchange VSS Writer (インスタンス GUID) は、正常にストレージ グループを保持しました。

イベントの種類 : 情報

イベント ソース : MSExchangeIS

イベント カテゴリ : Exchange VSS Writer

イベント ID : 9612

ユーザー : 該当なし

コンピュータ : ServerName.contoso.com

全般 : Exchange VSS Writer (インスタンス GUID) は、正常にストレージ グループの保持を解除しました。

バックアップ プログラムはシャドウ コピー バックアップ セットの整合性を検証する必要がある

バックアップ プログラムで、バックアップが正常に完了したことを Exchange に通知する前に、シャドウ コピー バックアップ セットの整合性を検証することを推奨しています。これには、次のような理由があります。

バックアップが正常に行われると、Exchange によって次の 2 つの処理が実行されます。

  • Exchange は、最後に正常にバックアップが行われた時刻を示すように、バックアップされたデータベースのヘッダーを更新します。
  • Exchange はトランザクション ログを切り詰めます。この場合、Exchange は、最後に正常に実行されたバックアップからロールフォワードするために必要ではなくなったトランザクション ログ ファイルを削除します。  

したがって、バックアップ プログラムが整合性の検証を Exchange でこれらのタスクが実行されるまで延期した場合、最後に検証されたバックアップと共に、特定のバックアップで必要なすべてのトランザクション ログ ファイルのコピーを保持することに注意を払う必要があります。バックアップが正常であると既に Exchange にレポートされている場合でも、バックアップ プログラムが整合性の検証操作を正常に完了するまでは、このバックアップを信頼しないでください。

整合性チェックを実行する方法および保持する必要があるデータベース ファイルやトランザクション ログ ファイルを判断する方法の詳細については、このトピックの「VSS バックアップの整合性の検証」を参照してください。

元の場所への復元操作には Exchange Writer を使用する必要がある

Exchange 関連ファイルを元の場所に復元する復元操作には、Exchange Writer のみを使用する必要があります。元の場所とは、VSS バックアップの作成元の Exchange サーバーと同じ名前の Exchange サーバーの同じファイル パスです。

Exchange Writer は、シャドウ コピーの復元操作時に、以下のイベントをアプリケーション ログに記録します。

イベントの種類 : 情報

イベント ソース : MSExchangeIS

イベント カテゴリ : Exchange VSS Writer

イベント ID : 9620

ユーザー : 該当なし

コンピュータ : ServerName.contoso.com

全般 : Exchange VSS Writer (インスタンス GUID) は、復元前のイベントを正常に処理しました。

イベントの種類 : 情報

イベント ソース : MSExchangeIS

イベント カテゴリ : Exchange VSS Writer

イベント ID : 9618

ユーザー : 該当なし

コンピュータ : ServerName.contoso.com

全般 : Exchange VSS Writer (インスタンス GUID) は、復元後のイベントを正常に処理しました。

VSS バックアップの整合性の検証

Exchange ストリーミング バックアップ API を使用してデータベースをバックアップする場合、データベースの各ページが順に読み込まれ、バックアップ処理時に各ページのチェックサム整合性が検証されます。トランザクション ログ ファイルのチェックサム整合性も、トランザクション ログ ファイルがバックアップされる前に検証されます。

一方、VSS バックアップ時には、Exchange で各データベース ファイルを読み込んで、チェックサム整合性を検証する機会がありません。したがって、データベースおよびトランザクション ログ ファイルの整合性をバックアップ プログラムで検証する必要があります。このような検証チェックを実行するには、Eseutil コマンドを実行します。

VSS バックアップのチェックサム検証を実行しない場合、破損したページが検出されないままデータベースに残る可能性があります。破損したページは、最終的には、利用可能なすべてのバックアップに存在する可能性があります。このような状況から回復する方法は、データベースを修復することだけです。データベースの修復には、長時間に及ぶダウンタイムが必要になり、一部のデータが失われる場合があります。破損した各データベース ページに含まれていたデータは失われます。

ただし、最新の VSS バックアップにすべて正常なページが含まれていることを検証した場合は、破損したページをデータベースから削除できます。そのためには、検証されたバックアップを復元し、正常なバックアップが行われた後に作成されたトランザクション ログを使用してバックアップをロールフォワードします。この操作に必要なダウンタイムは、一般的に、データベースの修復操作の場合よりも短時間です。また、この種類の回復操作は、データを失うことなく実行できます。したがって、バックアップに含まれるすべてのファイルのチェックサムが検証されるまでは、VSS バックアップが正常であると見なさないでください。

バックアップの整合性を検証するには、次の 2 つのルールに従うことをお勧めします。

  • 常にデータベース ファイルの整合性が検証されたコピーを保持する必要があります。整合性が検証されたバックアップは、バックアップ セット内のデータベース ファイルについて、ページのチェックサム検証が完了したバックアップです。
  • 整合性が検証された最新のデータベース ファイルを回復するために必要となるすべてのトランザクション ログ ファイルをバックアップする必要があります。さらに、トランザクション ログ ファイルのチェックサム レベルの整合性を検証する必要があります。

必要なトランザクション ログには、少なくとも、最後に検証されたバックアップに含まれている各データベース ファイルのヘッダーの Log Required フィールドに示されている範囲のログ ファイルが含まれます。これらのログ ファイルが利用できない場合、データベースを復元してもマウントできません。

important重要 :
これらの要件は、最後に整合性が検証されたバックアップに適用され、最新のバックアップには適用されません。最新のバックアップは、チェックサム検証が正常に終了するまでは、有効なバックアップとは見なされません。

必要に応じて、データベースを復元した後でデータベースを完全にロールフォワードするために必要な追加のトランザクション ログ ファイルを保持することもできます。この追加のログには、Log Required に示されている範囲の最も古いファイルから、Exchange サーバーから削除された最も新しいトランザクション ログ ファイルまでの一連のトランザクション ログがすべて含まれます。これらのファイルの例と説明は後で示します。

Log Required の範囲に示されているもの以外のトランザクション ログ ファイルを保存することは省略できます。ただし、省略できるというのは、バックアップされたデータベースを正常に復元およびマウントするために、ログファイルを保持することが厳密には要求されていないという意味です。適切なログ ファイルをすべて保持していない場合、バックアップからの復元によって、バックアップの作成以降にデータベースで行われたすべての変更が失われます。

バックアップされたデータベースを復元およびマウントするのに必要なトランザクション ログ ファイルと共に、それ以降のデータベースをロールフォワードするのに必要なすべてのトランザクション ログ ファイルも保持しておくことを強くお勧めします。

必要なトランザクション ログ ファイルを判断するには、次の操作を行います。

オンライン状態の Exchange データベースをバックアップする場合、常に少なくとも 1 つのトランザクション ログ ファイルがデータベースと共にバックアップされます。この処理は、ストリーミング バックアップ API と VSS バックアップ API のどちらを使用するかに関係なく行われます。

オンライン バックアップを復元した後、トランザクション ログの情報をデータベースに適用する必要があります。この操作を、トランザクション ログ ファイルの再生と呼びます。各データベース ヘッダーの Log Required フィールドには、データベースに対して再生する必要があるトランザクション ログ ファイルの範囲のシーケンス (世代) 番号が記録されます。

Log Required フィールドに "0-0" と表示される場合、追加のトランザクション ログ データを再生せずに、データベースをマウントできます。Log Required の値が 0-0 になるのは、データベースがクリーン シャットダウン状態になった後だけです。データベースが実行されている間、Log Required フィールドは常に、データベースに適用されていないトランザクション ログの範囲を記録しています。この範囲は継続的に更新されます。

オンライン状態でバックアップされたデータベースの Log Required の範囲は常に 0 以外です。したがって、データベースと共に適切なトランザクション ログ ファイルをバックアップする必要があります。データベースを復元した後でログ ファイルが使用できない場合、データベースをマウントできません。必要なログ ファイルを入手できない場合は、データベースの修復操作を実行する必要があります。ただし、データベースの修復操作が成功する保証はありません。また、データベースの修復操作では、一定レベルのデータの損失は避けられず、少なくとも不足しているログ ファイルのデータは失われます。

Exchange ストリーミング バックアップ API または Exchange Writer に含まれている VSS バックアップ API を使用する場合、データベースのマウントに必要なログ ファイルは自動的にデータベースと共にバックアップされます。Log Required フィールドに示された範囲のログ ファイルのみを再生すると、データベースはバックアップが完了した時点の状態に復元されます。それ以降のデータベースのロールフォワードを実行する場合は、バックアップの完了後に生成されたログ ファイルも再生する必要があります。

特定のバックアップ以降のデータベースのロールフォワードを完全に実行するには、Log Required に示された範囲の最も古いログからデータベースのストレージ グループにある最新のログ ファイルまで、一連のログ ファイルをすべて保持する必要があります。一連のログ ファイルのいずれかが不足しているか、破損している場合、その不足または破損しているファイルより前の正常なログ ファイルの時点までしかロールフォワードを実行できません。

そのため、データをまったく失うことなくバックアップから復元するには、最新の正常な検証済みデータベース バックアップ以降のすべてのトランザクション ログ ファイルの正常なコピーを保持することが必要です。

トランザクション ログの切り詰め

トランザクション ログ ファイルが Exchange サーバーから削除されない場合、ログ ファイルは利用可能なディスク領域がなくなるまで蓄積されます。したがって、ストリーミング API と VSS バックアップ API はいずれも、通常のバックアップまたは増分バックアップの完了後のトランザクション ログ ファイルのプルーニングをサポートしています。バックアップが正常に完了したことがバックアップ プログラムから Exchange に通知されると、最新のバックアップを復元するために必要なログ ファイルより古いログ ファイルがサーバーから自動的に削除されます。

ストリーミング API では、バックアップ中にデータベースのチェックサムが検証されます。バックアップ操作が完了するまでに、データベース全体と必要なログ ファイルの物理的な整合性が確認されます。VSS API では、実際のバックアップ処理の中でチェックサムを検証することはできません。バックアップ プログラムのベンダは、バックアップ処理とは別にデータベースの物理的な整合性を確認する必要があります。この検証は、バックアップ処理の前、またはバックアップの完了をプログラムが Exchange に通知した後に、Eseutil コマンドを使用して実行できます。

  • バックアップの完了前にチェックサム検証を実行してバックアップ セットに問題が見つかった場合は、バックアップが正常に完了しなかったことが Exchange に通知されます。これにより、Exchange によってサーバーからログ ファイルが切り詰められないようにすることができます。
  • チェックサムの検証をバックアップ完了の通知後まで遅らせると、Exchange によって古いログ ファイルがサーバーから削除されます。削除されたログ ファイルの中に、以前の正常なバックアップからのロールフォワードに必要なファイルが含まれている可能性があります。これらのログ ファイルのコピーを作成していなかった場合、ロールフォワードを完全には実行できない可能性があります。

バックアップ プログラムから Exchange にバックアップの完了を通知する前に、VSS バックアップのチェックサムを検証することをお勧めします。バックアップ完了後までチェックサムの検証を遅らせる場合、Exchange のロールフォワードを完全に実行できるようにすることが重要であれば、切り詰められるすべてのトランザクション ログ ファイルのコピーをバックアップ プログラムで保持する必要があります。

ほとんどの場合、VSS バックアップのロールフォワードに必要なすべてのトランザクション ログは、前回のバックアップで保存されたログ ファイルと、最新のバックアップで保存されたログ ファイルの中に含まれています。ただし、バックアップ ソリューションを選択するときには、必要なログ ファイルのコピーが保持されるかどうかを確認する必要があります。

未検証のバックアップの復元

バックアップのチェックサムの検証が完了する前に、バックアップからデータベースを復元することが必要になる場合があります。このような場合は、以前の検証済みバックアップからデータベースを復元し、そのバックアップのロールフォワードを実行することをお勧めします。この方法は、未検証のバックアップを使用するよりも適切です。

ただし、サービス レベル契約の要件によっては、前回のバックアップから復元するよりも短時間でデータを復元することが必要になる場合があります。この場合、前回の検証済みバックアップとそのバックアップからの完全なロールフォワードに必要なすべてのログ ファイルを保持していれば、未検証のバックアップを復元する方が適していることがあります。これらの要件を満たしていれば、未検証のバックアップに問題があることがわかった場合でも、既知の正常なバックアップからロールフォワードを実行することができます。

スナップショットの整合性のチェック

VSS リクエスタは、スナップショットの整合性を検証する必要があります。スナップショットの整合性の検証は、Exchange チームからバックアップ ソリューションのサポートを受けるための要件です。Exchange 2007 では、次の 2 つの方法でスナップショットの整合性をチェックすることをサポートしています。

  • CHKSGFILES API
  • Eseutil コマンドライン ツール

CHKSGFILES API を使用してスナップショットの整合性を検証する方法の詳細については、「Validating Backup Integrity By Using CHKSGFILES」 (このサイトは英語の場合があります) を参照してください。

Eseutil コマンドライン ツールを使用してスナップショットの整合性を検証する方法の詳細については、「Validating Backup Integrity By Using Eseutil」 (このサイトは英語の場合があります) を参照してください。

ボリューム シャドウ コピー サービスのトラブルシューティング

既定では、VSS は Windows Server 2008 と共にインストールされます。このサービスのスタートアップの種類は [手動] に設定されています。このサービスは、バックアップ プログラム (リクエスタ) が VSS Writer を使用できる場合に開始されます。

Exchange 2007 VSS バックアップで問題が発生した場合は、次のアイテムを使用して問題を解決できます。

  • イベント ログの情報
  • VSSADMIN コマンド
  • 診断ログ
  • Exchange Extra ツール
  • BETest ツール

イベント ログの情報

以下の手順では、VSS を使用する場合の Exchange 2007 のバックアップ処理と、ログに記録される対応するイベントについて説明します。バックアップ操作時にログに記録されたイベントを調べることによって、障害が発生しているコンポーネントを特定できます。

手順 1: データベースの準備

  1. バックアップ プログラム (エージェントとも呼ばれる) がスケジュールされたジョブを実行します。
  2. バックアップ プログラム内の VSS リクエスタが、VSS に対して、選択された Exchange ストレージ グループのスナップショット バックアップの準備の要求を送信します。
  3. VSS は Exchange VSS Writer にスナップショット バックアップを準備するよう通知します。

次の表に、バックアップ インスタンスが開始されるたびにアプリケーション ログに記録される一連のイベントを示します。

イベント ID イベントの種類 イベント ソース 全般

9604

情報

MSExchangeIS

Exchange VSS Writer は、バックアップまたは復元の準備としてメタデータ ドキュメントを正常に収集しました。

9818

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、"EcPrepareSGForBackup" に対して呼び出されました。

データ :

0000: 54 68 69 72 64 20 53 74 Third St

0008: 6f 72 61 67 65 20 47 72 orage Gr oup.

9811

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 56) は、ストレージ グループ 'Third Storage Group' の完全バックアップまたはコピー バックアップのためにデータベース エンジンを正常に準備しました。次の 1 個のデータベースがマウントされ、バックアップされます。

Third Storage Group

データ :

0000: 46 75 6c 6c 00 完全。

9606

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27) は、正常にバックアップの準備をしました。

9818

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、"CVssIExchWriter::OnPrepareSnapshot" に対して呼び出されました。

9608

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、正常にスナップショットの準備をしました。

2005

情報

ESE

Information Store (2256) シャドウ コピー インスタンス 56 を開始しています。これは、完全シャドウ コピーとなります。

手順 2: データベースのスナップショット

Exchange Writer が VSS にバックアップの準備が完了したことを通知すると、次の処理が行われます。

  1. Exchange Writer は適切な Exchange データベースの状態を保持します。この場合、Exchange は次の処理を実行します。

    • Exchange は特定のストレージ グループに対する管理操作を禁止します。
    • Exchange はストレージ グループのボリュームの依存関係を確認します。
    • Exchange は該当するデータベース ファイルとトランザクション ログ ファイルへのすべての書き込み操作を中断します。
      note注 :
      Exchange はデータベース ファイルとトランザクション ログ ファイルに対する読み取りアクセスを許可します。
  2. Exchange は Exchange データベース ファイルとトランザクション ログ ファイルを保持する処理を開始するときに、データベースのスナップショット コピーの作成にかかる時間を追跡するワーカー スレッドを開始します。コピー処理に 10 秒より長くかかることは許可されていません。

スナップショット コピー処理全体は 70 秒以内である必要があります。これには、「手順 2: データベースのスナップショット」のすべての処理も含まれます。処理全体で 70 秒を超える場合、ワーカー スレッドはタイムアウトになります。タイムアウトになると、Exchange はバックアップ ジョブを停止し、Exchange ストレージ グループの保持を解除します。その後、Exchange は通常の処理を続行できます。

次の表に、スナップショット処理時にアプリケーション ログに記録される一連のイベントを示します。

イベント ID イベントの種類 イベント ソース 全般

2001

情報

MSExchangeIS

MSExchangeIS (2256) Third Storage Group:シャドウ コピー インスタンス 56 の保持を開始しました。

9818

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、"CVssIExchWriter::OnFreeze" に対して呼び出されました。

9610

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、正常にストレージ グループを保持しました。

9818

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、"CVssIExchWriter::OnThaw" に対して呼び出されました。

2003

情報

ESE

Information Store (2256) シャドウ コピー インスタンス 56 の保持を停止しました。

9612

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、ストレージ グループの保持を正常に解除しました。

9818

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、"CVssIExchWriter::OnPostSnapshot" に対して呼び出されました。

手順 3: シャドウ コピーの検証

バックアップ プログラムの VSS リクエスタが、シャドウ コピーの状態を検証します。次に、このプログラムはバックアップが正常に完了したかどうかを Exchange に通知します。この処理により、バックアップ操作の完了が通知されます。OnBackupComplete() メソッドを使用して、backupInProgress フラグがリセットされます。

次の表に、バックアップの完了時にアプリケーション ログに記録される一連のイベントを示します。

イベント ID イベントの種類 イベント ソース 全般

9818

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、"CVssIExchWriter::OnBackupComplete" に対して呼び出されました。

9818

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、"EcSGBackupComplete" に対して呼び出されました。

データ :

0000: 54 68 69 72 64 20 53 74 Third Storage Group.

9780

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、ストレージ グループ 'Third Storage Group' の完全バックアップまたは増分バックアップを正常に完了しました。

2006

情報

ESE

Information Store (2256) シャドウ コピー インスタンス 56 は正常に完了しました。

9616

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、バックアップ完了イベントを正常に処理しました。

バックアップ処理が終了すると、Exchange Writer は OnBackupShutdown() メソッドを呼び出します。このメソッドを使用して、バックアップ ジョブが終了した後、バックアップ プログラムを終了するときに必要な処理を実行します。

致命的なエラーが発生した場合、OnBackupShutdown() メソッドは Exchange Writer の状態を Failed に設定します。

次の表に、BackupShutdown イベント発生時にアプリケーション ログに記録される一連のイベントを示します。

イベント ID イベントの種類 イベント ソース 全般

9818

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、"CVssIExchWriter::OnBackupShutdown" に対して呼び出されました。

9648

情報

MSExchangeIS

Exchange VSS Writer (インスタンス 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) は、バックアップのシャットダウン イベントを正常に処理しました。

バックアップでエラーが発生すると、次の 2 つの関数が呼び出されます。

  • CVssIExchWriter::OnAbort()
    このメソッドは、シャドウ コピーの処理が途中で終了したことを示します。Exchange Writer はこのメソッドを使用して、Exchange Writer をクリーンアップし、JET データベースにインフォメーション ストアの保持を解除 (解放) するよう指示します。また、Exchange Writer は、このメソッドを使用して、JET データベースにスナップショットが中止されたことを通知します。
  • CVssIExchWriter::EcBackupCleanup()
    バックアップでエラーが発生すると、Exchange はこのメソッドを使用して、バックアップ後のエラーのクリーンアップ処理を実行します。Exchange はこのメソッドを使用して、JET データベースにスナップショットでエラーが発生したことを通知します。また、Exchange はこのメソッドを使用して、インフォメーション ストアにスナップショットでエラーが発生したことを通知します。

手順 4: トランザクション ログの切り詰め

バックアップが正常に終了すると、Exchange は次の処理を実行します。

  • Exchange はトランザクション ログを切り詰めます。

    note注 :
    Exchange のバックアップを実行せずに、Exchange データベース ファイルを含むボリュームのスナップショット バックアップを実行した場合、バックアップは Exchange のバックアップと同様に処理されます。ただし、この場合、バックアップはコピー バックアップと見なされ、トランザクション ログの切り詰めは行われません。
  • Exchange は、適切な Log Required フィールドの情報を使用してデータベース ヘッダーを更新します。

  • Exchange は進行状況のバックアップを消去します。

  • Exchange は適切なデータベースの最後のバックアップの時刻を記録します。

VSSADMIN コマンド

VSS 管理コマンドライン ツール (VSSADMIN) を使用して、VSS に登録されているライタやプロバイダの情報を取得できます。

VSS ライタに関する情報を取得するには、次の手順を実行します。

  1. Exchange サーバーで、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、[OK] をクリックします。

  2. コマンド プロンプトで「vssadmin list writers」と入力し、Enter キーを押します。
    返された結果を調べて、Exchange Writer の情報を探します。Exchange Writer は安定状態である必要があります。Exchange Writer が安定状態である場合は、次のような結果が返されます。

    ライタ名: 'Microsoft Exchange Writer'

    ライタ Id: {76fe1ac4-15f7-4bcd987e-8e1acb462fb7}

    ライタ インスタンス Id: {977637c2-fcdd-463e-b1f8-a9a5d603a2e8}

    状態: [1] 安定

    最後のエラー: エラーなし

    "状態" の値が "安定" 以外である場合は、Microsoft Exchange インフォメーション ストア サービスを再起動します。Exchange Writer がエラー状態である場合、次のような結果が返されます。

    ライタ名: 'Microsoft Exchange Writer'

    ライタ Id: {76fe1ac4-15f7-4bcd987e-8e1acb462fb7}

    ライタ インスタンス Id: {977637c2-fcdd-463e-b1f8-a9a5d603a2e8}

    状態: [14] 失敗

    最後のエラー: 再試行できるエラー

  3. 登録されている VSS プロバイダに関する情報を取得するには、コマンド プロンプトで「vssadmin list providers」と入力します。次のような結果が表示されます。

    プロバイダ名: 'Microsoft Software Shadow Copy provider 1.0'

    プロバイダの種類: System

    プロバイダ ID: {b5946137-7b9f-4925-af80-51abd60b20d5}

    バージョン: 1.0.0.7

    既定では、Microsoft Software Shadow Copy provider のみが表示されます。ただし、サード パーティのバックアップ プログラムがインストールされている場合は、他のプロバイダが表示されることがあります。

note注 :
利用可能なコマンドの詳細については、コマンド プロンプトで「vssadmin /?」と入力してください。

診断ログ

発生している問題の原因が Exchange Writer であると疑われる場合は、Exchange Writer の診断ログを有効にします。そのためには、以下の手順を実行します。

  1. Exchange 管理シェルを起動します。

  2. 次のコマンドを実行します。

    get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level expert 
    
  3. Exchange Writer のログ出力レベルを確認するには、次のコマンドを実行します。

    get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"}
    
  4. 診断ログの出力レベルを既定のレベルに戻すには、次のコマンドを実行します。

    get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level Lowest
    

Exchange 2007 Extra ツール

Exchange 2007 に含まれている Troubleshooting Assistant (Extra) ツールを使用して、Exchange Writer を追跡できます。そのためには、以下の手順を実行します。

  1. Exchange サーバーで、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「extra」と入力し、[OK] をクリックします。

  2. このプログラムを以前に実行したことがない場合は、[Microsoft カスタマ エクスペリエンス向上プログラムに参加する] または [今回はプログラムに参加しない] をクリックします。

  3. 作業ウィンドウで、[タスクを選択する] をクリックします。

  4. トラブルシューティング タスク選択画面で、[トレースを制御する] をクリックします。

  5. 次のメッセージが表示されたら、[OK] をクリックします。

    このサーバーには、トレースを解釈するために必要なモジュールがありません。認定された Exchange サポート エンジニアの直接の監督下で実行する場合にのみ続行してください。

  6. [トレース ファイルの場所を選択してください] ボックスに表示されるパスをメモします。

  7. [手動トレース タグを設定する] をクリックします。

  8. [トレースするコンポーネント] の一覧で [ストア] をクリックします。[ストア] チェック ボックスはオンにしないでください。

  9. [トレース タグ] の一覧で、[tagVSS] チェック ボックスをオンにします。

  10. [トレースを開始する] をクリックします。

BETest ツール

BETest ツールを使用して、問題の原因がサード パーティの VSS リクエスタであるかどうかを判断できます。

BETest ツールは、Exchange VSS Writer をテストするために使用できるテスト用のリクエスタです。BETest ツールは、Microsoft VSS API を使用して Exchange Writer と通信し、Writer をテストします。BETest ツールでは、一般的な VSS リクエスタが実行するタスクの多くを実行できます。BETest ツールを使用して、Exchange ストレージ グループの VSS バックアップを作成できます。BETest によって、Exchange 2007 サーバー上のアクティブなデータベースやレプリカ データベースの VSS スナップショットを作成できます。

このツールを入手するには、VSS SDK Version 7.2 をダウンロードしてインストールします。この SDK を入手するには、「Volume Shadow Copy Service SDK 7.2」 (英語) を参照してください。

次のパスは、i386 版の BETest の既定のインストール先です。

C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\i386

note注 :
AMD64 版の BETest も利用できます。BETest を実行する前に、オペレーティング システムに対応する適切なバージョンが含まれているディレクトリに移動します。

BETest を使用するには、次の手順を実行します。

  1. コマンド プロンプトを開き、オペレーティング システムに対応する適切なディレクトリに移動します。たとえば、C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64 ディレクトリに移動します。

  2. 利用可能な VSS ライタを確認します。そのために、「betest.exe >AvailableWriters.txt」と入力します。

  3. BETest で使用するための Components.txt ファイルを作成します。そのためには、以下の手順を実行します。

    1. メモ帳などのテキスト エディタで AvailableWriters.txt ファイルを開きます。

    2. Microsoft Exchange Writer セクションを探します。メモ帳で、F3 キーを押し、[検索する文字列] ボックスに「Microsoft Exchange Writer」と入力し、[次を検索] をクリックします。

    3. WriterName = Microsoft Exchange Writer セクションに表示される情報を使用して、Components.txt ファイルを設定します。このファイルは次のような形式になっています。

      "<WriterIdGUID>": "<component-logical-path>" {"target" # "new target", ...}, ..."<component-logical-path>" : "<subcomponent-logical-path>,...";

      このファイルで、<component-logical-path> は、LogicalPath エントリ、LogicalPath エントリとコンポーネント GUID、またはコンポーネント GUID のみ (LogicalPath の値が存在しない場合) を表します。コンポーネント GUID は特定のストレージ グループを表します。たとえば、<component-logical-path> エントリは、"Microsoft Exchange Server\Microsoft Information Store\ServerName\000dd565-c4e8-4f58-a8b1-2e29eee4f5c0" のようになります。
      次に、サンプル Components.txt ファイルを示します。

      "{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\ServerName\999dd565-c4e8-4f58-a8b1-2e29eee4f5c0 ";

      この例では、最初の GUID は Exchange Writer の GUID です。この GUID は変更できません。2 番目の GUID は特定のストレージ グループに属しています。適切なストレージ グループの GUID を指定することによって、コマンドの対象となるストレージ グループを指定できます。特定のストレージ グループの GUID を取得するには、Get-StorageGroup '<StorageGroupName>' | fl GUID コマンドレットを実行します。
      Exchange では、アクティブなストレージ グループに対してのみストリーミング バックアップをサポートしています。したがって、パッシブなストレージ グループをバックアップするには、VSS バックアップを使用する必要があります。Exchange クラスタ連続レプリケーション (CCR) クラスタがある場合や、ローカル連続レプリケーション (LCR) が有効になっているサーバーからレプリカ コピーをバックアップする場合は、Components.txt ファイルは次の例のようになります。
      CCR パッシブ コピーの場合

      "{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\<Clustered Mailbox Server Name>\<Storage Group GUID>";

      LCR パッシブ コピーの場合

      "{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\<Server Name>\<Storage Group GUID>";

  4. Components.txt ファイルを作成した後、次のコマンドを実行してストレージ グループをバックアップします。

    BETEST.exe /B /E /T 1 /S output.XML /C components.txt /D c:\betest > output.txt
    
    note注 :
    このコマンドは、C:\Betest ディレクトリにバックアップを作成します。/E オプションを指定せずにこのコマンドを実行することもできます。
  5. このコマンドの実行時にエラー メッセージが表示された場合は、Exchange Writer に問題があります。問題を解決するには、手順 4. でコマンドを実行したときに作成された Output.txt ファイルの内容を確認します。

ベスト プラクティス

VSS バックアップの問題を解決する際に推奨されるベスト プラクティスのいくつかを次に示します。

  • 最新の Windows Service Pack と最新の VSS 更新プログラムがインストールされていることを確認します。
  • バックアップ ジョブを開始しようとしたときに発生した -2403 エラーを解決しようとしているとします。この場合、VSS ではスタートアップの種類として [手動] を使用しています。バックアップ ジョブがハングした場合でも、VSS は停止しない可能性があります。代わりに、VSS はバックアップがまだ実行されていると判断する場合があります。このような場合、新しいバックアップ ジョブを開始しようとすると、-2403 エラーが発生します。この問題を解決するには、手動で VSS を停止した後、バックアップ ジョブを開始します。
  • BETest プログラムを使用して問題を解決する場合は、このプログラムを使用して数日間にわたって複数の BETest バックアップをキャプチャします。また、BETest プログラムを実行するときには、サード パーティのバックアップ関連サービスを停止し、一時的に無効にします。
  • VSS ライタでタイムアウトの問題が発生した場合は、サーバーでパフォーマンスの問題が発生している可能性があります。このような場合は、パフォーマンス ログを収集して、パフォーマンスの問題があるかどうかを判断します。
  • VSS ライタが "再試行できる" 状態になっています。この問題は、VSS ライタで致命的ではないエラーが発生していることを示します。この状態は、しばらくすると自動的に変更されます。ただし、サーバーを再起動することによって、"再試行できる" 状態の問題を解決できます。

VSS リファレンス

VSS 関連のリファレンスには、次のようなものがあります。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。