Exchange のオフライン バックアップと復元処理

文書翻訳 文書翻訳
文書番号: 296788 - 対象製品
この記事は、以前は次の ID で公開されていました: JP296788
すべて展開する | すべて折りたたむ

目次

概要

この資料では、オンライン バックアップ API (アプリケーション プログラミング インターフェイス) を使用せずに、手動で Exchange インフォメーション ストア データベースをバックアップおよび復元する方法について説明します。1 台の Exchange Server 上に複数のストレージ グループが存在している場合、オフライン バックアップおよび復元を行うとき、各ストレージ グループは個別の独立した単位であると考える必要があります。 オフライン バックアップおよびスナップショット バックアップの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
296787 [XADM] Exchange Server 4.0、5.0、および 5.5 でのオフライン バックアップと復元の手順

詳細

この資料の内容は以下のとおりです。

はじめに

オフライン バックアップを実行する前に、以下の情報が手元にあることを確認します。
  • ストレージ グループの循環ログが有効になっているかどうかを調べます (Exchange では、デフォルトで循環ログは無効になっています)。循環ログが有効になっているかどうかを調べるには、Exchange システム マネージャで storage_group オブジェクトのプロパティを開き、[全般] ページを表示します。循環ログを無効にするには、[循環ログを有効にする] チェック ボックスをオフにします。循環ログのオプションに加えた変更は、ストレージ グループ内の各データベースを停止するまで有効にはなりません。

    オフライン バックアップを実行するために、循環ログを無効にする必要はありません。ただし、復元したオフライン バックアップにトランザクション ログを再生する場合は、循環ログを無効にする必要があります。
  • Exchange データベース ファイル、ストリーミング ファイル、トランザクション ログ ファイル、とチェックポイント ファイル パスの場所およびストレージ グループのログ ファイルの先頭文字を調べます。

    この情報を見つけるには、Exchange システム マネージャで storage_group オブジェクトのプロパティを開き、[全般] ページを表示します。以下の 3 つのボックスの値を記録します。
    • [ログ ファイルの先頭文字] (E0n は、E00、E01、E02、または E03 のいずれかです)
    • [トランザクション ログの場所] (E0n*.log)
    • [システム パスの場所] (E0n.chk)
    データベース パスは各 database_name オブジェクトのプロパティの [データベース] タブに表示されています。ストレージ グループのデータベースごとに、以下の 2 つのフィールドの値をメモします。
    • [Exchange データベース] (.edb)
    • [Exchange ストリーミング データベース] (.stm)
Exchange システム マネージャを利用できない場合、上記のすべての情報を検索するには、ADSIEDIT または LDIFDE などのツールを使用して Active Directory から生の属性を直接読み取ることができます。次の LDIFDE コマンドを使用して、Active Directory フォレストに存在するすべての Exchange Server の情報を出力できます。

: コマンド行は、読みやすいように折り返してあります。
LDIFDE -F EXPATHS.TXT -D "CN=CONFIGURATION,DC=configuration_container_domain,DC=top_level_domain" -L MSEXCHESEPARAMLOGFILEPATH,MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME,MSEXCHESEPARAMCIRCULARLOG,MSEXCHSLVFILE,
MSEXCHEDBFILE -R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
以下に上記のコマンドの出力例を示します。
D:\exchsrvr\mdbdata>ldifde -f con -d "cn=configuration,dc=test,dc=com" -l msexch eseparamlogfilepath,msexcheseparamsystempath,msexcheseparambasename,msexchesepar amcircularlog,msexchslvfile,msexchedbfile -r "(|(msexcheseparamlogfilepath=*)(ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*)(msexchedbfi le=*)(msexcheseparamcircularlog=*))"
"dc1.child.test.com" に接続しています
SSPI を使用して現在のユーザーとしてログオンしています
ディレクトリをファイル EXPATHS.TXT にエクスポートしています
エントリを検索しています

<一部省略>

.dn: CN=First Storage Group,CN=InformationStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Excha nge,CN=Services,CN=Configuration,DC=Test,DC=com
changetype: add
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.dn: CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=Informati onStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Tes t,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.dn: CN=Private Information Store (Exchange1),CN=First Storage Group,CN=Informat ionStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Te st,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
トランザクション ログを正常に再生するには、ファイルのバックアップ作成元のパスの場所と同じ場所にデータベース ファイル (.edb と .stm) を復元する必要があります。たとえば、データベース ファイルを E:\Mdbdata フォルダから、ストリーミング データベース ファイルを F:\Mdbdata フォルダからバックアップした場合、それぞれのファイルを E:\Mdbdata フォルダと F:\Mdbdata フォルダに復元する必要があります。この制限は、まったく異なるサーバーにデータベースを復元する場合にも適用されます。たとえば、単一のメールボックスを回復するような場合です。

最後にバックアップした後にデータベース パスを変更すると、トランザクション ログの一部分しか再生できず、データベース パスを元の場所に戻した場合のみ、部分的な再生をアーカイブできます。元のパスに戻すと、最長でパスが変更された時点までのログを再生できます。

トランザクション ログにはトランザクション ログがアタッチされているデータベースの場所が記録されていますが、データベースにはトランザクション ログの場所は記録されていません。そのため、元のバックアップの保存場所以外のパスにトランザクション ログ (E0n*.log) を復元できます。再生中に、ログはトランザクション ログ ヘッダーに格納されているパス情報を使用してデータベースを検索します (オンライン バックアップ API はデータベース パスの変更を内部的に補正するため、この制限は適用されません)。

チェックポイント ファイル (E0n.chk) のバックアップまたは復元は実行されません。ただし、回復中にチェックポイント ファイルの調査や削除が必要な場合があるため、チェックポイント ファイルが現在置かれている場所を把握している必要があります。

セクションの一覧に戻る

Exchange データベース ファイルの相互関係

.edb ファイルと .stm ファイルはすべてのデータベース情報の最終的なリポジトリです。多くの場合、これらの 2 つのファイルは 1 つのファイルとしてまとめて取り扱われます。これらのファイルは相前後してバックアップおよび復元されます。これらのファイルの日付は互いに同期している必要があります。.edb ファイルがある特定の日にバックアップされている場合、その .edb ファイルを別の日にバックアップされたストリーミング ファイルと一致させることはできません。

Exchange 2000 Server または Exchange Server 2003 Enterprise Edition は最大で 4 つのストレージ グループをサポートできます。各ストレージ グループは最大 5 つのデータベースをサポートできます。ストレージ グループは、共通する一連のトランザクション ログ ファイルを共有するデータベースの集まりです。Microsoft Exchange Server 5.5 は最大で 1 つのストレージ グループをサポートし、ストレージ グループは最大 2 つのデータベース (プライベート インフォメーション ストアとパブリック インフォメーション ストア) をサポートします。

データベースに変更が加えられると、変更はまず現在のトランザクション ログ ファイルに書き込まれ、その後メモリ内キャッシュに書き込まれます。変更がキャッシュに書き込まれると、その変更は直ちにユーザーに表示されます。キャッシュにあるページは、適時データベース ファイルにフラッシュされます。チェックポイントは、すべてのトランザクションが物理的にデータベース ファイルにフラッシュされた時点までのログ ファイルの順序でマークされます。チェックポイントが現在のログ ファイルよりも 3 つ以上前のログ ファイルをマークすることがありますが、これは正常な動作です。

ログ ファイルが属しているストレージ グループについて混乱を避けるため、指定されたストレージ グループに属している Exchange ログは、一意なログ先頭文字で名前が付けられています。このログ先頭文字には、ファイル名の最初の 3 文字が使用されます。Exchange 2000 Server または Exchange Server 2003 Enterprise Edition でサポートされている 4 つのストレージ グループの有効なログ ファイル先頭文字は E00、E01、E02、および E03 です。この資料では、ストレージ グループのログ ファイルの先頭文字に E0n を使用しています。ストレージ グループの現在のログ ファイルは常に E0n.log です。

トランザクション ログのサイズは 5 MB に固定されています。現在のログ ファイルがいっぱいになると、ログ ファイルはログ生成番号と呼ばれる 16 進数のシーケンス番号を使用して、名前が変更され、現在のログ ファイルは新しく生成されます。ログ ファイルは、E0n00001.log、E0n00002.log などのように番号が付けられます。この資料では、番号付きのログ ファイルには汎用性のある E0nxxxxx.log が使用されています。

データベースが異常停止すると、回復処理がデータベースを整合性のある状態に復元するために再生する必要のあるトランザクション ログが、チェックポイント ファイル (E0n.chk) に記録されます。この処理は "ソフトウェア エラーからの回復" と呼ばれます。ソフトウェアからの回復と "ハードウェアからの回復" を比較すると、ハードウェアからの回復はオンライン バックアップを復元した後にログ ファイルを再生する処理です。ソフトウェアからの回復とハードウェアからの回復の最も重要かつ異なる点は、ハードウェアの回復中に修正プログラム ファイルのデータがログ ファイル再生処理に挿入されることです。

不整合な状態にある Exchange データベース ファイルとは、すべての未解決のトランザクションがまだ書き込まれていないファイルです。通常の操作中における Exchange のデータベース ファイルは、物理的にファイルにまだ書き込まれていない情報がキャッシュにあるため、その状態は不整合です。Exchange データベース ファイルを整合性の取れた状態にあると見なすことができるのは、一般的に、データベース サービスが正常にシャットダウンされた後のみです。ただし、全体的に見ると (トランザクション ログ ファイルとデータベース ファイルの両方にある情報の合計として考えると) 必要なログ ファイルが途中で削除されない限り、データベースは常に整合性が取れています。

セクションの一覧に戻る

Exchange データベースをオフラインでバックアップする

Exchange データベースをオフラインでバックアップするには、次の手順を実行します。
  1. バックアップするデータベースをマウント解除します。ストレージ グループに存在するすべてのデータベースをマウント解除する必要はなく、バックアップするデータベースのみをマウント解除します。
  2. データベース ファイル (.edb ファイルと .stm ファイルの両方) が整合しており、互いに一致していることを確認します。この確認を行うには、各ファイルに対して次のコマンドを実行します。
    eseutil /mh database file | find /i "DB Signature"
    : Exchange 2000 Service Pack 2 以降では、データベースの状態は "Consistent (整合)" か "Inconsistent (不整合)" かではなく、"Clean Shutdown" か "Dirty Shutdown" かで報告されます。"Clean Shutdown" の意味は "Consistent" と同じで、"Dirty Shutdown" の意味は "Inconsistent" と同じです。Exchange 2000 Service Pack 2 以降では、次のコマンドも実行して、各データベースの状態を調べます。
    eseutil /mh database_name | find /i "Shutdown"
    以下に上記のコマンドの出力例を示します。
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    上記の例では、DB Signature (データベースの署名) が同一です。データベースの署名が同じ場合、.edb ファイルと .stm ファイルが同じ一連のファイルに属していることを証明します (署名が一致していると見なされるには、両方の行のすべての文字が一致している必要があります)。

    データベースの署名が一致しているだけでなく、すべてのファイルが互いに同期され、整合性が取れている必要もあります。ファイルごとに次のコマンドを実行します。
    eseutil /mh database file | find /i "consistent"
    上記のコマンドを実行すると生成される出力の例を以下に示します。
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    上記の例では、両方のファイルは "State: Consistent" を報告しています。各ファイルのかっこ内の 16 進数の番号 (0x2CC7,1F14,1F7) も一致している必要があります。Last Consistent のタイムスタンプは一致している必要はありません。これらの両方のファイルは、互いに一貫性があり一致しています。

    いずれかのファイルが "State: Inconsistent" をレポートするか、または Last Consistent のログ位置が同期されていない場合、データベースは正常にマウント解除されていません。データベースをもう一度マウントおよびマウント解除します。ファイルが正しく一致せず、整合性が取れない場合の詳細については、Microsoft Product Support Services (PSS) にお問い合わせください。
  3. 各 .edb データベース ファイルとそれに対応する .stm ストリーミング データベース ファイルをバックアップの保存先にコピーします。
  4. バックアップの保存先にコピーしたデータベースをマウントします。
  5. 循環ログが有効になっている場合、この手順は省略します。循環ログが無効になっている状態で "ロールフォワード" を後から実行する場合、すべての番号付きのトランザクション ログ ファイル (E0nxxxxx.log ファイル) をバックアップする必要があります。E0n.log、Res1.log、および Res2.log ファイルはバックアップしないでください。

    番号付きのログ ファイルは必要に応じてバックアップできます。ログ ファイルは E0n.log から E0nxxxxx.log に名前が変更された後、Exchange によって名前が変更されることはないため、ファイルが作成された直後でもバックアップできます。ただし、ログ ファイルのバックアップを削除する場合は、手順 6. の指示に従う必要があります。

    ログ ファイルのバックアップはデータベースのバックアップと 1 対 1 で対応していません。各ログ ファイルのバックアップは、複数の異なるデータベースのバックアップに対して再生できる一連のログ ファイルのリンクです。データベースのヘッダーの "Last Consistent" の行に指定されているログで始まる連続するログを保持している限り、特定のデータベースのバックアップからロールフォワードできます。この資料で、最終整合ログは "低アンカー ログ" として参照されます。

    上記の例を参照すると、Last Consistent のエントリは (0x2CC7,1F14,1F7) です。これらの 3 つの番号はログ ファイル、ログ ファイルのページ、およびそのページへのバイト オフセットを示しています。各ログ ファイルは、約 10,000 ページを含んでおり、各ページは 512 バイトです。ページのオフセットは、ログ ファイルが後どのくらいでいっぱいになるかを示します (上記の例では、0x1F14 が 10 進数 7956 と等しく、約 80% 使用されています)。ただし、このオフセットは回復には無関係であり、回復は常にログ ファイルの先頭で開始されます。

    次の例では、低アンカー ログ ファイルは E0n02cc7.log です。

    ディスクの最終整合ログが E0n.log という名前のままである場合があるため、ディスク上の最終整合ログが番号付きログとして表示されないことがあります。データベースが停止されている間に、ログ ファイル ヘッダーを検査するとシーケンス番号の E0n.log ファイルが最終的に生成されることを確認できます (データベースの実行中は、E0n.log ヘッダーへのアクセスが拒否されます)。

    内部のログ生成番号を参照するには、次のコマンドを実行します。
    eseutil /ml [log file] | find /i "lGeneration"
    以下に上記のコマンドの出力例を示します。
    E:\mdbdata>eseutil /ml E00.log | find /i "lGeneration"
          lGeneration: 11463 (0x2CC7)
    							
    多くの状況において、データベースのバックアップの状態が良好であることを確認するより、ログ ファイルのバックアップの状態が良好であることを確認することが重要です。各データベースのバックアップは、ストレージ グループのその他のデータベースに対して冗長性のある回復は提供できますが、データベースのバックアップから完全回復を行う場合、バックアップが作成された後に作成されたログ ファイルが保存されている状態に依存します。
  6. 循環ログが有効になっている場合、この手順は省略します。チェックポイント ファイルのヘッダーを検査して、安全に削除できる番号が最も大きい番号付きログ ファイルを調べます。チェックポイントは、データベースが異常停止した場合に、自動回復に必要な最も番号が小さい番号付きログ ファイルを追跡します。チェックポイント ファイルを検査するには、次のコマンドを実行します。
    eseutil /mk E0n.chk
    以下に上記のコマンドの出力例を示します。
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    3 行目 Checkpoint の行は関連情報を含んでいます (LastFullBackupCheckpoint エントリはオンライン バックアップで使用され、データベースに対してオンライン バックアップが一度も実行されていない場合は、すべて 0 のままです)。Checkpoint のログ位置の形式はデータベース ヘッダーの Last Consistent のエントリと同じです。この例では、チェックポイントは E0002cc7.log にあります。

    循環ログが無効になっている場合、ログ ファイルは手動で削除されるか、またはオンライン バックアップ処理で自動的に削除されるまで蓄積されます。循環ログが有効になっている場合、チェックポイントが以前のログ ファイルをパススルーすると、データベース サービスが自動的に以前のログ ファイルを削除するため、以前のログ ファイルを管理するために特別な操作を行う必要はありません。

    番号付きのログ ファイルをすべてバックアップした後、チェックポイント ログまで (チェックポイント ログは含みません) のすべての番号付きログ ファイルを削除してディスク領域を解放することができます。

    重要 : チェックポイント ログを削除しないでください。

    この例では、E0002cc6.log までのログをすべて削除できます。
  7. この手順は省略可能です。Esefile ユーティリティを使用して、コピーしたデータベースの整合性をページ レベルで確認できます。

    Esefile.exe ファイルは Exchange Server 5.5 Service Pack 3 CD-ROM の Support フォルダ、または Exchange 2000 Server のインストール CD-ROM のいずれかから入手できます。また、Microsoft PSS からも Esefile.exe を入手できます。Esefile ユーティリティは Exchange Server 5.0 と 5.5、Exchange 2000、および Exchange 2003 の .edb ファイルで動作します。

    現在、オンライン バックアップ以外に .stm ファイルの各ページのチェックサムを確認する方法はありません。.stm ファイルは生のデータを含んでいます。このデータを構成するインデックスおよびポインタは .edb ファイルに存在します。.stm ファイルで問題が発生すると、特定のクライアント データが失われることがありますが、データベース全体の構造的または論理的な整合性は改ざんされません。

    Exchange データベースのページ チェックサムを確認するには、次の Esefile ユーティリティ コマンドを実行します。
    esefile /s database_name
    以下に上記のコマンドの出力例を示します。
    E:\mdbdata>esefile /s priv.edb
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    esefile completes successfully after 10 seconds
    							
    uninitialized pages が正常値ですが、データベースで問題が発生していなければ、"0 bad checksums" と "0 wrong page numbers" が表示されます。

    データベースが Esefile ユーティリティの整合性チェックにパスしない場合、以前の正常な状態のバックアップを復元して、データベースをロールフォワードするのが最善の方法です。正常な状態のバックアップを利用できない場合は、PSS に問い合わせのうえデータベースの修復または回復についてご相談ください。
  8. この手順は省略可能です。次のコマンドを使用してバックアップしたログ ファイルの整合性を確認できます。
    eseutil /ml E0n
    以下に上記のコマンドの出力例を示します。
    k:\backups>eseutil /ml E00
    							
    このコマンドはバックアップしたログ ファイルを含むフォルダから実行する必要があります。現在実行中のログ ファイルに対してこのコマンドを実行できますが、ストレージ グループのデータベースが実行されているときに Eseutil が E0n.log ファイルのヘッダーを読み取ると、-1032 エラー (JET_errFileAccessDenied) が表示されます。

    このコマンドはログ ファイルの破損を検出して、連続するファイルの途中でファイルが欠如しているか、またはログ ファイルで署名の不一致が存在する場合に警告します。
セクションの一覧に戻る

Exchange データベースのオフライン バックアップを復元する

このセクションでは、オフライン バックアップを復元する 2 つの方法について説明します。
  • "時刻を指定した" 復元。データベースに再生されるログ ファイルはありません。バックアップ後に生成されたデータはすべて失われます。
  • "ロールフォワード" による復元。バックアップ後に作成されたログ ファイルがデータベースに再生されます。すべてのログ ファイルを利用できる場合、バックアップ後に生成されたすべてのデータを保持できます。循環ログを有効にしている場合、"時刻を指定した" 復元でオフライン バックアップを復元します。"ロールフォワード" による復元はできません。
復元する一連のファイルは、以下の最低条件を満たしている必要があります。
  • 時刻を指定した復元では、ストレージ グループで停止されているすべてのデータベースの整合性が取れており、有効なチェックポイント ファイルが存在している必要があります。現在のチェックポイント ファイルまたは既存のログ ファイルを削除しないでください。
  • ロールフォワードによる復元では、ストレージ グループのすべてのデータベースが停止される必要があり、整合性が取れている必要があります。バックアップが作成された時刻より後に生成されたログ ファイル (現在の E0n.log を含みます) がすべて存在している必要があります。チェックポイント ファイルを削除する必要があります。
一連のファイルが上記の条件を満たしていない場合、復元および再生は必ず失敗するとは限りませんが、ソフトウェア エラーからの回復中に -1216 エラー メッセージ (JET_errAttachedDatabaseMismatch) が表示される可能性が高くなります。

セクションの一覧に戻る

-1216 エラーに対処する

Exchange が手動で変更されたデータ ファイルを検出し、現在のデータ セットを使用して回復を実行すると以前のデータが損失すると判断した場合、Exchange 2000 以降に追加されたソフトウェア エラーの回復の保証が -1216 エラーを発生させます。

以前のバージョンの Exchange では、一連のファイルが完全でなくても再生を正常に行うことが可能である場合、管理者に警告メッセージを表示することなくソフトウェア エラーの回復を開始しました。Exchange 2000 以降では管理者は Eseutil を使用して明示的に -1216 を上書きする必要があります。 セクションの一覧に戻る

オフライン バックアップの時刻を指定した復元

オフライン バックアップの時刻を指定して復元を実行するには、以下の手順を実行します。
  1. 復元するデータベースが現在マウントされている場合は、マウント解除します。同じストレージ グループで他のデータベースがマウント解除されている場合は、マウント解除されているデータベースのデータベースおよびストリーミング ファイル (.edb と .stm) は、それぞれ整合性があり一致している必要があります (整合性および一致の確認をするには、この資料の「Exchange データベースをオフラインでバックアップする」の手順 2. を参照してください)。

    ストレージ グループのすべてのデータベースがマウント解除されている場合、すべてのデータベースは整合性が取れている状態であり、かつ有効なチェックポイント ファイルが存在している必要があります。有効なチェックポイント ファイルは、ストレージ グループのデータベースが前回実行されていたときに使用されており、チェックポイントとして E0n.log ファイルが指定されているヘッダーを持つチェックポイント ファイルです。グループにマウントされているデータベースが存在する場合、有効なチェックポイント ファイルは現在システムが使用しているチェックポイント ファイルです。ストレージ グループのいずれかのデータベースが実行されている場合、有効なチェックポイント ファイルは存在します。

    すべてのデータベースが停止されているときにチェックポイント ファイルを確認するには、以下のコマンドを実行します。
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    以下に上記のコマンドの出力例を示します。
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    上記の例では、チェックポイントは lGeneration の 0x2cc7 と一緒にログ (e00.log) に存在します。チェックポイントは有効であると判断できます。

    チェックポイントが有効でない場合に、ストレージ グループのデータベースをマウントすると -1216 エラー メッセージ (JET_errAttachedDatabaseMismatch) が表示されることがあります。この問題は、ストレージ グループに存在するすべてのデータベースの整合性が取れている状態であっても、発生することがあります。
  2. バックアップした .edb と .stm を適切なデータベースの場所およびストリーミング ファイルの場所にコピーします (これらの場所を検出するには、この資料の「はじめに」を参照してください)。復元したファイルが整合性のある状態で、一致していることを確認します。

    : 復元するデータベース ファイルのコピーが既にサーバー上に存在する場合、データベースをバックアップする前にサーバー上にあるファイルをバックアップします (既存のファイルが起動可能でない場合も同様です)。既存のファイルは修復可能である場合があり、Exmerge ユーティリティを使用して、これらのファイルからデータを回復できることがあります。
  3. 復元したデータベースをマウントします。データベースは E0n.log ファイルにデータベース自身をアタッチします。データベースが正常に起動された後、以前のログ ファイルをデータベースに再生することはできません。階層内に数千のフォルダを含む Public フォルダのデータベースは起動するまでに時間がかかることがあります。階層内の 1,000 のフォルダを開始するごとに少なくとも 1 分かかることを考慮する必要があります。

    以前のバージョンの Exchange Server では、インフォメーション ストア データベースのオフライン バックアップを復元後に、ISINTEG -patch コマンドを実行して、インフォメーション ストア データベースをディレクトリと同期させる必要がありました。Exchange データベースに修正プログラムを適用する必要がある場合、システムが自動的に修正プログラムを適用します。ただし、データベースが別のサーバー、別のストレージ グループ、別の論理データベース オブジェクトに復元されるか、またはデータベースが Active Directory で削除され、再作成されたことが原因で別の Active Directory オブジェクトに復元された場合は除きます。このような場合、次のエラー メッセージがアプリケーション イベント ログに記録されます。
    種類 : エラー
    ソース : MSExchangeIS Mailbox Store
    分類 : General
    イベント ID : 1087
    日付 : 2001/05/04
    時刻 : 20:33:42
    ユーザー : N/A
    コンピュータ : EXCHANGE1
    説明 : インフォメーション ストアはオフライン バックアップから復元されました。データベース "First Storage Group\Private Information Store" の復元を Microsoft Exchange システム マネージャで許可しているため、このデータベースには修正プログラムを適用することができます。
    この問題を解決するには、Exchange システム マネージャのデータベース オブジェクトのデータベース プロパティで [復元時はこのデータベースを上書きする] チェック ボックスをオンにする必要があります。
セクションの一覧に戻る

オフライン バックアップのロールフォワードによる復元

復元したデータベースにログ ファイルを正常に再生するには、以下の手順を実行する必要があります。
  • 最も古い完全バックアップが実行された時間より後に作成されたすべてのトランザクション ログのコピーを保持します。
  • データベースのパスを変更した直後は、必ず新しい完全バックアップを作成します。
  • ESEUTIL /p または ESEUTIL /d を実行した直後は、必ず新しい完全バックアップを作成します。
  • ストレージ グループにデータベースを追加または削除した直後は、必ずストレージ グループに存在するすべてのデータベースの完全バックアップを作成します。
復元処理を開始するには、以下の手順を実行します。
  1. 復元するデータベースがマウントされている場合、マウント解除します。その後、復元するデータベース ファイルをサーバー上の適切なパスにコピーします。復元するデータベース ファイルのコピーが既にサーバー上に存在する場合、データベースをバックアップする前にサーバー上にあるファイルをバックアップします (既存のファイルが起動可能でない場合も同様です)。既存のファイルは修復可能である場合があり、Exmerge ユーティリティを使用してこれらのファイルからデータを回復できることがあります。
  2. ストレージ グループのすべてのデータベースをマウント解除して、現在のストレージ グループに存在するすべてのデータベースと、復元したすべてのデータベース ファイルに対して次のコマンドを実行します。
    eseutil /mh database_file_name| find /i "consistent"
    : Exchange 2000 Service Pack 2 以降では、データベースの状態は "Consistent (整合)" か "Inconsistent (不整合)" かではなく、"Clean Shutdown" か "Dirty Shutdown" かで報告されます。"Clean Shutdown" の意味は "Consistent" と同じで、"Dirty Shutdown" の意味は "Inconsistent" と同じです。Exchange 2000 Service Pack 2 以降では、次の追加コマンドを実行して、各データベースの状態を調べます。
    eseutil /mh database_name | find /i "Shutdown"
    以下に上記のコマンドの出力例を示します。
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    このコマンドには 3 つの目的があります。
    • データベース ファイルがそれぞれ整合性の取れた状態であることを確認します。
    • 各データベースの .edb ファイルおよび .stm ファイルが互いに対応する組であることを確認します。
    • 低アンカー ログ ファイルと高アンカー ログ ファイルを識別します。これらのファイルは、-1216 エラーを生成せずにすべてのデータを正常に回復するために必要な最初のログ ファイルと最後のログ ファイルです。すべてのデータベースの中で Last Consistent の値が最も低いものが低アンカー ログ ファイルで、Last Consistent の値が最も高いものが高アンカー ログ ファイルです。
    上記の例では、低アンカー ログ ファイルは E0002ac8.log で高アンカー ログ ファイルは E0002cc7.log です。
  3. 各データベース ヘッダーに記録されているログ署名が低アンカー ログの署名と同一であることを確認します。
    eseutil /mh database_name| find /i "Log Signature"
    eseutil /ml low_anchor_log| find /i "Signature"
    以下に上記のコマンドの出力例を示します。
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:
    							
    1 つのログ ファイルで複数の署名が報告されることがあります。最初の署名は常にログ ファイル自身の署名ですが、残りの署名はログ ファイルの作成時に実行されていたデータベースの署名です。上記の例では、データベース ファイルに記録されている署名は低アンカー ログ ファイルのログの署名と一致しています。

    低アンカー ログを見つけられない場合、ログをデータベースに再生できません。低アンカー ログ ファイルを見つけられない場合、ログ ファイルをデータベースに再生できません。低アンカー ログが見つからない場合の対応には、次の 2 つの方法があります。
    • すべてのログ ファイルを削除します。すべてのデータベースは整合性が取れている状態であるため、ログ ファイルが存在しなくてもデータベースを起動できます。ただし、データベースに存在しないデータを回復できる機会は失われます。
    • 低アンカー ファイルから高アンカー ファイルまで連続する一連のログを構成できるように、Last Consistent の値が最も低いデータベースを削除できます。それから、残りのデータベースで回復を実行します。削除したデータベースをストレージ グループに戻すと、それらのデータベースにデータを追加で再生できません。
  4. 現在のデータベース パスの場所が、バックアップ作成時の場所と同じであることを確認します。

    バックアップを作成後、トランザクション ログのパスおよび作業パスを変更できますが、ログ ファイルを再生できるのはデータベースがバックアップ元と同じ場所に存在している場合のみです。データベースの元の場所が不明な場合は、次のコマンドを実行します。
    eseutil /ml "Last_Consistent"_log| find /i "database name or pattern"
    以下に上記のコマンドの出力例を示します。
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    : 一連のログ ファイルの最初のログのヘッダーは最初のデータベースがログにアタッチされる前に作成されるため、低アンカー ログ ファイルが E0n00001.log である場合、ヘッダーにはパス情報が含まれていません。この場合、データベースのパス情報を参照するには、次のログ ファイルのヘッダーを確認する必要があります。まれなケースですが、ログ ファイルが作成されてからログ ストリームにデータベースが作成またはアタッチされる場合があるため、1 つ目以降のログ ファイルにもパス情報が含まれないこともあります。
  5. 低アンカー ログ ファイルから連続しているすべてのログ ファイルを集めて、現在のトランザクション ログのパスにコピーします。サーバー上に既に存在しているログ ファイルをバックアップせずにログ ファイルを上書きしないでください。この操作を行うには、複数の種類のバックアップ メディアからログ ファイルを復元する必要が生じる場合があります。

    上記の例では、低アンカー ログ ファイルは E0002ac8.log で、高アンカー ログ ファイルは E0002cc7.log です。利用できるログを検査すると、番号が最も大きい番号付きログ ファイルにおいて、必要であると思われる数字よりも 1 小さいことがあります (たとえば、E0002cc7.log ではなく E0002cc6.log です)。通常、この現象は E0n.log がまだいっぱいになっておらず、E0n.log の名前がシーケンス番号に変更されていないために発生します。E0n.log が実際に高アンカー ログ ファイルであるかどうかを確認するには、次のコマンドを実行して、ログ ファイル ヘッダーの IGeneration の値を検査する必要があります。
    eseutil /ml E0n.log | find /i "lGeneration"
    以下に上記のコマンドの出力例を示します。
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    : Eseutil ユーティリティを使用してログ ファイルのヘッダーを参照するには、/ml スイッチを使用します。データベース ファイルのヘッダーを参照するには、/mh スイッチを使用します。これらのスイッチを混同すると、このコマンドの出力は正しく表示されません。

    一般的に、高アンカー ログ ファイルは利用できる番号付きログ ファイルの最も番号が大きなログ ファイルです。ただし、以下の場合を除きます。
    • 障害によってログ ファイルが破損しました。

      または
    • ストレージ グループに存在するすべてのデータベースを一度に復元しています。
    最初の場合、回復中に -1216 エラーが発生する可能性が高くなります。2 番目の場合、IGeneration の値から連続している限りは高アンカー ログ ファイルよりも新しいログ ファイルを再生できます。
  6. すべてのログが同じログの署名を共有しており、番号が連続していることを確認します。次のコマンドを実行します。
    eseutil /ml E0n > filename.txt
    以下に上記のコマンドの出力例を示します。
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    d:\mdbdata>type logverify.txt
    Microsoft(R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.
    Initiating FILE DUMP mode...
    Verifying log files...
          Base name: e00
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    No damaged log files were found.
    Operation completed successfully in 3.305 seconds.
    							
    Eseutil コマンドにより、ログ ファイルの破損チェック、ログ ファイルのシーケンス番号で欠如している番号の報告、および署名の不一致の検出が実行されます。

    再生候補のすべてのログ ファイル間でログの署名は一致している必要があります。再生を開始する前に、一致した署名を持たないログを削除する必要があります。

    この時点 (確認テストを通過しなかったファイルを削除した後) でトランザクション ログ フォルダに存在するトランザクション ログ ファイルは、以下のファイルです。
    • 低アンカー ログ ファイルで始まり、少なくとも高アンカー ログ ファイル (可能な場合は高アンカー ログ ファイルよりも新しいファイル) まで IGeneration が連続しているファイル
    • ログの署名が一致しているファイル
  7. 高アンカー ログ ファイルの名前がまだ E0n.log に変更されていない場合は、このファイル名を変更します。
  8. システム パス フォルダから E0n.chk ファイルを削除します。

    チェックポイント ファイルが存在しない場合、Exchange Server はトランザクション ログ フォルダの利用できる最も番号が小さい番号付きログ ファイル (低アンカー ログ ファイル) からログを再生し始めます。E0n.chk ファイルが存在する場合、Exchange Server はこのファイルに記録されているチェックポイントで再生を開始します。E0n.chk が低アンカー ログ ファイルよりも新しいログ ファイルをポイントしている場合、復元された一連のファイル全体で再生が失敗します。多くの場合、チェックポイント ファイルの操作を誤るとバックアップからデータベース ファイルの復元をすべてやり直す必要があります。
  9. ストレージ グループをマウントする前の最終確認として、以下を確認します。
    • すべてのデータベース ファイルは実行パスに存在している必要があります。
    • 実行中のトランザクション ログの場所に存在するログ ファイルは、低アンカー ログ ファイルから少なくとも高アンカー ログ ファイルまで続くファイルです。この場合、利用できる最も新しいログ ファイルは E0n.log です。
    • システム パス フォルダに E0n.chk ファイルは存在しません。
    これで、ストレージ グループを正常にマウントして、この一連のファイルを使用してトランザクション ログの再生を開始できるようになります。回復が終了してデータベースが起動されても、再生中に発生したデータベースの署名とパスの問題が原因で、ログ ファイルのすべてのデータが実際には回復されていないことがあります。これらの問題に関する詳細については、この資料の「データベースの署名とパスの不一致に対処する」を参照してください。
  10. インフォメーション ストアがまだ実行されていない場合は、インフォメーション ストアを実行して、ストレージ グループのデータベースを少なくとも 1 つマウントします。この操作によって、ソフトウェア エラーの回復がストレージ グループに存在するすべてのデータベースに対して実行されます。

    以前のバージョンの Exchange Server では、インフォメーション ストア データベースのオフライン バックアップを復元した後に、ISINTEG -patch コマンドを実行して、インフォメーション ストア データベースをディレクトリと同期させる必要があります。Exchange データベースに修正プログラムを適用する必要がある場合、システムが自動的に修正プログラムを適用します。ただし、データベースが別のサーバー、別のストレージ グループ、別の論理データベース オブジェクトに復元されるか、またはデータベースが Active Directory で削除され、再作成されたことが原因で別の Active Directory オブジェクトに復元された場合は除きます。このような場合、次のエラー メッセージがアプリケーション イベント ログに記録されます。
    種類 : エラー
    ソース : MSExchangeIS Mailbox Store
    分類 : General
    イベント ID : 1087
    日付 : 2001/05/04
    時刻 : 20:33:42
    ユーザー : N/A
    コンピュータ : EXCHANGE1
    説明 : インフォメーション ストアはオフライン バックアップから復元されました。データベース "First Storage Group\Private Information Store" の復元を Microsoft Exchange システム マネージャで許可しているため、このデータベースには修正プログラムを適用することができます。
    この問題を解決するには、Exchange システム マネージャでデータベース オブジェクトのデータベース プロパティの [復元時はこのデータベースを上書きする] チェック ボックスをオンにする必要があります。
データベースが起動されたときに発生する可能性があるエラーや損傷については、Microsoft Windows NT イベント ビューアでアプリケーション イベント ログを参照します。再生した各ログ ファイルに対してイベント ID 301 が表示されます。回復処理中に発生したエラーや警告を注意深く確認します。

セクションの一覧に戻る

データベースの署名とパスの不一致に対処する

ログ ファイルなどのデータベースは独自の署名を保持しています。ログの署名は E0n000001.log ファイルが作成された後に変更されることはありませんが、データベースの物理的なトポロジが変更されると、データベースの署名は変更され、この変更はログ ファイルで監視されません。Eseutil を使用してオフラインでデータベースを最適化または修復すると、データベースの署名は変更されます。このようなイベントの後で、データベースは以前と同じログ ストリームにアタッチできますが、データベースが以前の署名を保持していたときに実行したトランザクションの再生をデータベースは許可しません。これは、以前のデータベースでは、データベースの署名が変更された後に実行されたトランザクションの再生が許可されないためです。

データベースの署名はこのようにリセットされるため、オフラインでデータベースの最適化または修正を行った直後にデータベースの完全バックアップを作成することを強くお勧めします。後で以前の署名を使用するデータベースのコピーを復元すると、署名が変更された時点までの再生には成功しますが、それ以降の変更はすべて失われます。

データベースのパスがログ ストリームの途中で変更された場合、署名が変更されたときと同様の影響があります。再生はパスが変更された時点で中止されます (オンライン バックアップ API では、回復中にパスを再マップする機能が提供されているため、オンライン バックアップ API ではバックアップが作成されてからパスが変更された場合でも、ログが完全に再生されます)。

データベースの署名やデータベースのパスの問題は再生中に発生するため、データベースの署名やデータベースのパスの問題は、ログ ファイルごとに再生のイベント ID 301 と一緒にアプリケーション イベント ログに出力されます。この問題が発生したログ ファイルより後のログ ファイルは正常に再生されたように見えますが、これは単に同じ不一致の警告が繰り返しログに出力されていないだけです。一般的に、あるデータベースへの再生は、そのデータベースを参照しているデータベースの署名またはデータベースのパス エラーが最初に発生した時点で切断されます。

セクションの一覧に戻る

関連情報

この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 296788 (最終更新日 2003-10-09) を基に作成したものです。

プロパティ

文書番号: 296788 - 最終更新日: 2007年12月3日 - リビジョン: 4.3
この資料は以下の製品について記述したものです。
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
キーワード:?
kberrmsg kbhowto kbproductlink KB296788
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com