文書番号: 822896 - 最終更新日: 2007年12月3日 - リビジョン: 8.3 Exchange Server 2003 のデータ バックアップとボリューム シャドウ コピー サービス目次概要
Microsoft Windows Server 2003 のボリューム シャドウ コピー サービス機能を使用して、Microsoft Exchange Server 2003 のバックアップと復元を行うアプリケーションを作成できます。Windows ボリューム シャドウ コピー サービス (VSS) は、サードパーティの記憶域管理プログラム、ビジネス プログラム、およびハードウェア プロバイダが連係してシャドウ コピーを作成し、管理することを可能にするインフラストラクチャを提供します。このインフラストラクチャに基づくソリューションでは、シャドウ コピー (またはミラー コピー) を使用して 1 つ以上の Exchange Server 2003 データベースのバックアップと復元を行うことができます。
ボリューム シャドウ コピー サービスは、リクエスタ (バックアップ アプリケーション)、ライタ (Exchange Server 2003 や SQL Server 2000 などの Windows サービスのアプリケーション)、プロバイダ (シャドウ コピーを作成するシステム コンポーネント、ソフトウェア コンポーネントまたはハードウェア コンポーネント) の間の通信を調整します。ボリューム シャドウ コピー サービスを使用して Exchange Server 2003 をバックアップするには、バックアップ プログラムに、Exchange Server 2003 に対応するボリューム シャドウ コピー サービス リクエスタが含まれている必要があります。Windows Server に含まれているバックアップ プログラムにはそのようなリクエスタがないため、サードパーティのバックアップ アプリケーションを使用する必要があります。 VSS ベースのバックアップ アプリケーションが Exchange Server 2003 に準拠するためには、シャドウ コピー バックアップの整合性と回復性を保証する 3 つの基本要件を満たす必要があります。Microsoft Product Support Services (PSS) では、これらの要件を満たしていないバックアップ ソリューションを Exchange VSS フレームワークから外れていると見なし、そのソリューションで発生するバックアップや復元の問題のトラブルシューティングは実施できません。使用するバックアップ アプリケーションがこのサポート技術情報資料に記載されている Exchange に準拠するための条件を満たしているかどうかをベンダに確認してください。Exchange VSS の要件の詳細については、この資料の「詳細」を参照してください。 すべてのサードパーティ ソリューションと同様、バックアップと復元の問題についての主要なサポート プロバイダはバックアップ アプリケーションのベンダです。PSS は、利用可能なデータベースとトランザクション ログ ファイルで発生する問題の解析または分析を支援することができます。ただし、マイクロソフトでは、サードパーティ製品のトラブルシューティングとデバッグは行いません。PSS の支援は、利用可能なデータベースとトランザクション ログ ファイルの復元を続行するための最適な方法についてのアドバイスに限定されます。 VSS ベースのソリューションに対する PSS のサポートの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。 841696?
(http://support.microsoft.com/kb/841696/
)
サードパーティ製ストレージ ソフトウェア ソリューションに対するマイクロソフトのサポート ポリシーの概要 詳細ボリューム シャドウ コピー サービス プロセスを使用した Exchange Server 2003 のバックアップ
ボリューム シャドウ コピー サービスを使用した Exchange Server 2003 のバックアップの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。 842066?
(http://support.microsoft.com/kb/842066/
)
[TechNet Support WebCast] Exchange Server 2003 のボリューム シャドウ コピー
シャドウ コピー バックアップ アプリケーションが満たす必要のある Exchange Server 2003 の要件以下に、Exchange データベースの整合性と回復性を保証するためにすべてのシャドウ コピー バックアップ アプリケーションが満たす必要のある Exchange Server 2003 の要件と、各要件が満たされているかどうかを明らかにする具体的なアプリケーション イベント ログを示します。バックアップ アプリケーションと Exchange サーバーによって、バックアップと復元の処理に関連するその他のイベントが出力されることがあります。バックアップと復元の実行中に以下のイベントが出力される場合、そのバックアップ アプリケーションは Exchange VSS の要件に準拠しています。現在、Exchange 上で動作するサードパーティ ソフトウェア ソリューション向け認定プログラムはありません。この場合の準拠とは、シャドウ コピー バックアップの整合性と回復性を保証するものであり、そのサードパーティ ソリューションのパフォーマンスや信頼性を保証するものではありません。
Exchange Server 2003 SP1 の段階では、元の場所以外への復元を Exchange Writer で実行することはできません。VSS ベースのバックアップ アプリケーションは、ユーザーの手作業またはプログラムを利用したその他の方法で、データベースのシャドウ コピーを元の場所とは異なる場所に復元する機能を提供できます。 VSS バックアップの整合性を検証する方法Exchange ストリーミング バックアップ API を使用してデータベースをバックアップする場合、データベースの各ページが順番に読み込まれ、各ページのチェックサムの整合性がバックアップ処理中に検証されます。バックアップが行われる前にも、トランザクション ログ ファイルのチェックサムの整合性がチェックされます。VSS のバックアップ中、Exchange が各データベース ファイル全体を読み取ってチェックサムの整合性を検証する機会はありません。そのため、データベースとトランザクション ログ ファイルの整合性の検証は、バックアップ アプリケーションが実行する必要があります。この整合性の検証を実行するには、この資料の最後に記載されている Eseutil を実行します。 VSS バックアップのチェックサムの整合性を検証しないと、データベース内の破損したページが検出されずに残り、破損したページが既存のすべてのバックアップに含まれる可能性があります。この状況から復旧する唯一の方法は、データベースの修復です。データベースの修復を行う場合、長時間のダウンタイムが必要になり、データの一部 (少なくとも破損したページ上にあるデータ) が失われます。 一方、最新の VSS バックアップのどのページにも問題がないことが検証されている場合、検証済みのバックアップを復元し、そのバックアップの作成後に作成されたトランザクション ログを使用してロール フォワードを実行することで、データベースから破損したページを削除できます。この作業に必要なダウンタイムは、通常、データベースの修復に必要なダウンタイムよりきわめて短くて済みます。この回復方法では、データをまったく失うことなくデータベースの問題を修正できます。 このため、データベース内のすべてのファイルのチェックサムが検証されるまで、VSS バックアップが正常であると見なさないようにする必要があります。 バックアップの整合性を検証するときは、以下の 2 つのルールに従ってください。
重要 : この要件は、最新のバックアップではなく、最新の整合性検証済みのバックアップに適用されます。最新のバックアップは、チェックサムの検証が正常に完了するまで有効なパックアップと見なされません。 状況に応じて、データベース バックアップの復元後に、データベースの完全なロール フォワードを実行するために必要なログも保存しておくことをお勧めします。この追加のログには、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 VSS Writer に含まれている VSS バックアップ API を使用する場合、データベースをマウントするために必要なログ ファイルがデータベースと共に自動的にバックアップされます。Log Required に示された範囲のファイルのみを再生すると、データベースはバックアップが完了した時点の状態に復元されます。それ以後のデータベースのロール フォワードを実行する場合は、バックアップの完了後に生成されたログ ファイルも再生する必要があります。 特定のバックアップ以降のデータベースのロール フォワードを完全に実行するには、Log Required に示された範囲の最も古いログからデータベースのストレージ グループにある最新のログ ファイルまで、一連のログ ファイルをすべて保持する必要があります。一連のログ ファイルのいずれかが不足しているか、破損している場合、その不足しているファイルまたは破損しているファイルより前の正常なログまでしかロール フォワードを実行できません。 そのため、データをまったく失うことなくバックアップから復元する必要がある場合は、最新の正常な検証済みデータベース バックアップ以降のすべてのトランザクション ログ ファイルの正常なコピーを保持することがきわめて重要です。 トランザクション ログのプルーニングトランザクション ログが Exchange サーバーから削除されない場合、ログは利用可能なディスク領域がなくなるまで蓄積され続けます。そのため、ストリーミング API と VSS バックアップ API はどちらも、通常のバックアップまたは増分バックアップの完了後のトランザクション ログのプルーニングをサポートしています。バックアップ アプリケーションから Exchange にバックアップの正常な完了が通知されると、最新のバックアップを復元するために必要なログ ファイルより古いログ ファイルがサーバーから自動的に削除されます。ストリーミング API では、バックアップ中にデータベースのチェックサムが検証され、データベース全体と必要なログ ファイルの物理的な整合性がバックアップの完了までに確認されます。VSS API では、実際のバックアップ処理の中でチェックサムを検証することはできません。ベンダは、バックアップ処理とは別にデータベースの物理的な整合性を確認する必要があります。この処理は、バックアップの完了を Exchange に通知する前または後のいずれかに、Eseutil を使用して行うことができます。 バックアップの完了前にチェックサムを検証してバックアップ セットに問題が見つかった場合は、バックアップが正常に完了しなかったことを Exchange に通知できます。これにより、Exchange によってサーバーからログ ファイルが削除されないようにすることができます。 チェックサムの検証をバックアップ完了の通知後まで遅らせると、Exchange によって古いログ ファイルがサーバーから削除されます。削除されたログ ファイルの中に、直前の正常なバックアップからのロール フォワードに必要なファイルが含まれている可能性があります。これらのログ ファイルのコピーを作成していなかった場合、ロール フォワードを完全に実行することはできません。 そのため、マイクロソフトでは、バックアップ アプリケーションから Exchange にバックアップの完了を通知する前に、VSS バックアップのチェックサムを検証することを推奨します。ただし、これは必須ではありません。バックアップ完了後までチェックサムの検証を遅らせる場合、ロール フォワードを完全に実行することが重要であれば、サーバーから削除されるすべてのトランザクション ログ ファイルのコピーの作成をバックアップ アプリケーションで保証する必要があります。 ほとんどの場合、VSS バックアップのロール フォワードに必要なすべてのトランザクション ログは、前回のバックアップで保存されたログ ファイルと、最新のバックアップで保存されたログ ファイルの中に含まれています。ただし、ユーザーは使用中のバックアップ アプリケーションによって必要なログ ファイルのコピーが保持されるかどうかを確認する必要があります。 未検証のバックアップの復元最新のバックアップのチェックサムの検証が完了する前に障害が発生し、復元が必要になることがあります。そのような場合、マイクロソフトでは、未検証のバックアップを使用せずに、以前の検証済みバックアップを復元し、そのバックアップのロール フォワードを実行することを推奨します。ただし、サービス レベル契約 (SLA) の要件によっては、前回のバックアップから復元するよりも短時間でデータを復元する必要がある場合があります。その場合、前回の検証済みバックアップとそのバックアップからの完全なロール フォワードに必要なすべてのログ ファイルを保持していれば、未検証のバックアップを復元する方が適していることがあります。これらの要件を満たしていれば、最新のバックアップに問題があることがわかった場合でも、既知の正常なバックアップからロール フォワードを実行することができます。 スナップショットの整合性チェックの方法VSS リクエスタは、スナップショットの整合性をチェックする必要があります。スナップショットの整合性をチェックするには、データベースとログ ファイルに対して次の表に示す適切なオプションで Eseutil.exe を実行し、返された ERRORLEVEL のすべてが負以外の値であることを確認します。コマンド ラインで ERRORLEVEL を確認するには、Eseutil.exe の実行の完了後に echo %errorlevel% を実行します。ERRORLEVEL が負の場合、ファイルに破損があることを意味しています。VSS リクエスタは BackupComplete を呼び出す前に、Backup Component Document 内のバックアップ コンポーネントの状態に整合性チェックの結果が反映されていることを確認する必要があります。つまり、バックアップ コンポーネントの状態は、破損が見つかった場合は FALSE、破損が見つからなかった場合は TRUE である必要があります。スナップショットの整合性の検証は、Exchange チームからソリューションのサポートを受けるための必須の要件です。次の表は、整合性チェックに使用するオプションをバックアップの種類ごとに示しています。 元に戻す
VSS バックアップはスナップであるため、JET ではすべてのページを読み取って必要な整合性チェックを実行する機会がありません。そのため、スナップショットの整合性は VSS リクエスタが保証する必要があります。 * スナップショットのデータベースの復元には、ログ ファイル世代番号がチェックポイント ログ ファイルと等しいかそれより大きいログ ファイルがすべて必要です。最新のログ ファイル (Enn.log) が存在する場合は、そのファイルもデータベースの復元に必要です。必要なログ ファイルのいずれかの整合性チェックで問題が見つかった場合、リクエスタは、BackupComplete を呼び出す前に、バックアップ コンポーネントの状態が FALSE に設定されていることを確認する必要があります。チェックポイント ログ ファイルを特定するには、スナップショット チェックポイント ファイルに対して eseutil.exe を実行し、出力で "Checkpoint" を探します。たとえば、"c:\eseutil.exe /mk E01.chk" を実行すると、次の出力が得られます。 Checkpoint: (0x20,9D,187) この例の場合、データベース自体の物理的な整合性チェックで問題がなかった場合でも、スナップショット データベースを復元するためには、E0100020.log 以降を含むすべてのログ ファイルが破損していないことが必要です。 ** データベースの復元には、増分バックアップ セットまたは差分バックアップ セットのログ ファイルがすべて必要です。一連のログ全体の整合性は、ログ ファイルのプレフィックスに対して eseutil を実行することにより確認できます。たとえば、"eseutil /k E01" を実行すると、指定したパスにある E01xxxxx.log 形式のすべてのファイルについて整合性チェックが実行されます。 関連情報この資料は以下の製品について記述したものです。
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。（Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。" | サポート技術情報の翻訳
|
| United States | Change | | | All Microsoft Sites |
Help and Support
先頭へ戻る
|
