Exchange 的離線備份與還原程序

文章翻譯 文章翻譯
文章編號: 296788 - 檢視此文章適用的產品。
本文曾發行於 CHT296788
全部展開 | 全部摺疊

在此頁中

結論

本文將告訴您,可以略過連線備份應用程式發展介面 (API),並手動備份與還原 Exchange 資訊儲存資料庫的方法。如果單一 Exchange 伺服器上有多個儲存群組,要進行離線備份與還原時,每個儲存群組都必須視為獨立且自我包含的單位。如需離線與快照備份的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:
296787 XADM:Offline Backup and Restore Procedures for Exchange Server 4.0, 5.0, and 5.5

其他相關資訊

開始之前

執行離線備份之前,請確認已經取得下列資訊:
  • 判斷儲存群組是否啟用了循環記錄(依預設 Exchange 會停用循環記錄)。如果要判斷是否啟用了循環記錄,請開啟 Exchange 系統管理員中 storage_group 物件的內容,然後檢視 [一般] 頁面。如果要停用循環記錄,請按一下以清除 [循環記錄] 核取方塊。對循環記錄的變更,在您停止儲存群組中的各個資料庫時才會生效。

    您不需停用循環記錄也可以執行離線備份。然而,如果您想要在還原的離線備份中重新顯示交易記錄檔,就必須停用循環記錄。
  • 判斷 Exchange 資料庫、資料流、交易記錄檔與檢查點檔案的路徑位置,以及儲存群組的記錄檔前置詞。

    如果要找出這些資訊,請開啟 Exchange 系統管理員中 storage_group 物件的內容,然後檢視 [一般] 頁面。記下下列三個方塊中的值:
    • 記錄檔前置詞 (E0n,其中 E0n 可能是 E00、E01、E02 或 E03)
    • 交易記錄位置 (E0n*.log)
    • 系統路徑位置 (E0n.chk)
    資料庫路徑會列在各個 database_name 物件的 [資料庫] 內容中。記下儲存群組中各個資料庫的下列兩個欄位的值:
    • Exchange 資料庫 (.edb)
    • Exchange 資料流資料庫 (.stm)
如果無法使用 Exchange 系統管理員,您可以使用 ADSIEDIT 或 LDIFDE 等工具,直接從 Active Directory 讀取原始屬性,以取得上述所有資訊。您可以使用下列的 LDIFDE 命令輸出 Active Directory 樹系中所有 Exchange 伺服器的資訊。

注意:為了方便讀者閱讀,下列命令文字已經加以換行。
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=*))"
Connecting to "dc1.child.test.com"
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries...

<輸出遭截斷>

.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 檔是所有資料庫資訊最後的儲存之處。在大部分用途中,請將這兩個檔案視為單一檔案,同時並行備份與還原。這兩個檔案必須按時間先後保持同步化;在不同日期備份的 .edb 檔和資料流檔案無法搭配使用。

Exchange 2000 或 Exchange 2003 伺服器最多可以支援四個儲存群組,而每個儲存群組最多可以支援五個資料庫。儲存群組是一組共用一組公用交易記錄檔的資料庫。Microsoft Exchange Server 5.5 最多只能支援一個儲存群組,而這個儲存群組最多可以支援兩個資料庫 (私人與公用資訊儲存庫)。

當您變更資料庫時,變更會先寫入目前的交易記錄檔,然後再寫入記憶體中的快取。只要變更一出現在快取中,使用者就可以看見這些變更。快取中的分頁會在適當時機排清至資料庫檔案。檢查點會以記錄檔的順序標示點,直到所有交易都已實際排清至資料庫檔案。檢查點在目前的記錄檔之後再標示三個或以上的記錄檔是正常的。

為了要避免弄不清楚哪些記錄檔屬於哪個儲存群組,Exchange 會以唯一的記錄檔前置詞來命名屬於特定儲存群組的記錄檔,前置詞就是檔案名稱的前三個字元。Exchange 2000 或 Exchange 2003 伺服器支援的四個儲存群組的有效記錄檔前置詞是 E00、E01、E02 與 E03。在本文中,是以 E0n 來代表儲存群組的記錄檔前置詞。儲存群組目前的記錄檔永遠是 E0n.log。

交易記錄檔的大小一律為 5 MB。如果目前的記錄檔已滿,會以一個十六進位序號重新命名,稱為記錄檔產生編號,並產生一個新的目前記錄檔。記錄檔會編號為 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 及更新版本不是將資料庫狀態回報為「一致」或「不一致」,而是「正常關機」或「不正常關機」。「正常關機」和「一致」的意思相同,「不正常關機」和「不一致」的意思相同。如果是 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:
    							
    在上面範例中,資料庫簽章是相同的,證明 .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」。每個檔案的括號中的十六進位編號 (0x2CC7,1F14,1F7) 也必須相符,但 Last Consistent 時間戳記不需相符。這兩個檔案是一致的並且相符。

    如果其中一個檔案回報「State:Inconsistent」或 Last Consistent 記錄位置沒有同步,表示您沒有完整的卸載資料庫。請裝載資料庫,然後再次卸載資料庫。如果檔案仍然不相符或不一致,請連絡「Microsoft 技術支援處」(PSS) 以取得進一步的協助。
  3. 將各 .edb 資料庫檔案與相對應的 .stm 資料流資料庫檔案複製到某個備份位置。
  4. 裝載已備份的資料庫。
  5. 如果啟用了循環記錄,請跳過這個步驟。如果停用循環記錄,而您稍後想要「向前還原」,就必須備份所有已編號的交易記錄檔 (E0nxxxxx.log 檔)。不要備份 E0n.log、Res1.log 與 Res2.log 檔。

    您可以在任何方便的時機備份已編號的記錄檔,甚至可以在建立之後立即備份,因為 Exchange 在將記錄檔從 E0n.log 重新命名為 E0nxxxxx.log 之後,就不會再更改這個檔案。但是,請依據步驟 6 中的指示來清除已備份的記錄檔。

    您的記錄檔備份和資料庫備份沒有一對一的對應關係。每個記錄檔備份都是記錄檔鏈結中的一個連結,可以對數個不同資料庫備份中的其中任何一個執行。只要有未中斷的記錄檔資料流 (從列於資料庫標頭的 Last Consistent 一行中的記錄檔開始),就可以從某特定資料庫備份向前還原。在本文中,最後一致的記錄檔稱為「低錨點記錄檔」。

    如果您參考上面範例,最後一致項目是 (0x2CC7,1F14,1F7)。這三個數字代表某個記錄檔、記錄檔中的某個分頁,以及分頁中的位元組位移。每個記錄檔都含有大約 10,000 頁 512 位元組的分頁。分頁位移可讓您瞭解記錄檔是否已滿 (上面範例中的記錄檔大概已滿了百分之 80,因為 0x1F14 相當於十進位的 7956),但和復原本身沒有關係。復原永遠是從記錄檔的開頭開始進行。

    在本範例中,低錨點記錄檔是 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)
    							
    第三行,也就是 Checkpoint 這一行,含有相關資訊 (LastFullBackupCheckpoint 項目是用於連線備份,如果從未對資料庫執行過連線備份,則此項目的內容會全部保持為零)。檢查點記錄位置格式會和資料庫標頭中最後的一致項目相同。在本範例中,檢查點是位於 E0002cc7.log 中。

    如果停用循環記錄,記錄檔會一直累積,直到您手動刪除記錄檔或在連線備份程序中自動移除為止。如果啟用循環記錄,就不需要特別管理舊的記錄檔,因為檢查點通過舊的記錄檔後,資料庫服務會自動刪除這些舊的記錄檔。

    在備份了所有的編號記錄檔之後,就可以移除到檢查點記錄檔為止所有的編號記錄檔 (但不包括檢查點記錄檔本身),以釋放磁碟空間。

    重要:請勿移除檢查點記錄檔。

    在本範例中,您可以移除到 E0002cc6.log 為止的所有記錄檔。
  7. 這個步驟是選擇性的。您可以使用 Esefile 公用程式來確認複製的資料庫的頁面等級完整性。

    您可以在 Exchange Server 5.5 Service Pack 3 CD-ROM、Exchange 2000 Server 安裝 CD-ROM 或 Exchange Server 2003 安裝 CD-ROM 上的 [Support] 資料夾中找到 Esefile.exe 檔,也可以從 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
    							
    未初始化的資料頁是可接受的,但完好的資料庫應該有 0 個不良的總和檢查碼以及 0 個錯誤的頁碼。

    如果資料庫沒有通過 Esefile 公用程式的完整性檢查,您最好是還原先前已知完好的備份,並向前還原資料庫。如果沒有這類備份,請連絡 PSS 以取得修復或挽救資料庫的建議。
  8. 這個步驟是選擇性的。您可以使用下列命令來確認已備份記錄檔的完整性:
    eseutil /ml E0n
    下列是上述命令的輸出範例:
    k:\backups>eseutil /ml E00
    							
    您必須從包含已備份記錄檔的資料夾執行這個命令。您也可以對目前執行中的記錄檔資料夾執行這個命令,但如果儲存群組中的任何資料庫正在執行時,Eseutil 試圖讀取 E0n.log 的標頭,您會收到 -1032 錯誤 (JET_errFileAccessDenied)。

    這個命令會偵測記錄檔中損毀的部分,如果一系列連續的記錄檔中間遺失了某個記錄檔,或者任何記錄檔之間有簽章不合的情形,這個命令都會警告您。

還原 Exchange 資料庫的離線備份

本節將告訴您兩個還原離線備份的方法:
  • 「時間點」還原。資料庫中不會重新顯示記錄檔。在備份之後建立的所有資料都會遺失。
  • 「向前還原」還原。資料庫中會顯示在備份之後建立的記錄檔。如果所有記錄檔都存在,備份之後所建立的所有資料就可以保存下來。如果啟用了循環記錄,您就必須執行「時間點」的離線備份還原方法;您不能選擇「向前還原」的還原方法。
您所還原的檔案組必須符合下列最基本的準則:
  • 如果是時間點還原,儲存群組中所有停止的資料庫都必須一致,而且必須要有有效的檢查點檔案。請勿刪除目前的檢查點檔案或是任何現有的記錄檔。
  • 如果是向前還原,儲存群組中的所有資料庫都必須停止並且一致,而且製作備份之後建立的所有記錄檔都必須存在 (包括目前的 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 檔的尾端。當資料庫順利啟動之後,就無法再在資料庫中重新顯示任何先前存在的記錄檔。在階層中包含數千個資料夾的公用資料夾資料庫可能要花很長的時間才能啟動。階層中每 1,000 個資料夾至少要花一分鐘的時間啟動。

    在舊版的 Exchange Server 中,在還原資訊儲存資料庫的離線備份之後,您通常還要執行 ISINTEG -patch 命令,以同步處理資訊儲存資料庫與目錄。當 Exchange 資料庫需要修補時,系統會自動執行修補作業,除非將資料庫還原至其他伺服器、儲存群組或邏輯資料庫物件,或是您曾經刪除資料庫的 Active Directory 物件,然後又在 Active Directory 中重新建立。在這些情況下,應用程式事件記錄檔中會記錄下列錯誤訊息。
    事件類型:錯誤
    事件來源:MSExchangeIS 信箱儲存區
    事件類別目錄:一般
    事件識別碼:1087
    日期:5/4/2001
    時間:8:33:42 PM
    使用者:N/A
    電腦: EXCHANGE1
    描述:The information store was restored from an offline backup.In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched. (從離線備份還原資訊儲存庫。在 Microsoft Exchange 系統管理員中,指出 First Storage Group\Private Information Store 資料庫允許還原,以便進行修補。)
    如果要解決這個問題,請在 Exchange 系統管理員、資料庫物件的 [資料庫] 內容中,按一下以選取 [此資料庫可被還原覆寫] 核取方塊。

離線備份的向前還原

如果要在還原的資料庫中順利地完整重新顯示記錄檔:
  • 請保存製作最舊的完整備份之後所建立的所有交易記錄檔的複本。
  • 請勿在沒有立即製作新的完整備份的情況下變更資料庫的路徑。
  • 請勿在沒有立即製作新的完整備份的情況下執行 ESEUTIL /pESEUTIL /d
  • 請勿在沒有立即製作儲存群組中所有資料庫的完整備份的情況下,新增或移除儲存群組中的資料庫。
如果要開始進行還原程序:
  1. 如果您想要還原的資料庫已裝載,請卸載資料庫,然後將要還原的資料庫檔案複製到伺服器上的適當路徑。如果伺服器上已經有想要還原的資料庫檔案的複本,即使現有的檔案無法啟動,仍然請在還原資料庫之前備份這些檔案。這些檔案或許可以修復,您可能可以使用 Exmerge 公用程式從這些檔案挽救資料。
  2. 卸載儲存群組中的所有資料庫,然後對目前的儲存群組中的各資料庫,以及各個還原的資料庫檔案執行下列命令:
    eseutil /mh database_file_name | find /i "consistent"
    注意:Exchange 2000 Service Pack 2 及更新版本不是將資料庫狀態回報為「一致」或「不一致」,而是「正常關機」或「不正常關機」。「正常關機」和「一致」的意思相同,「不正常關機」和「不一致」的意思相同。如果是 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
    							
    這個命令有三個目的:
    • 確認各資料庫檔案都一致。
    • 確認每個資料庫的 .edb 與 .stm 檔都是相符的配對。
    • 辨識低、高錨點記錄檔,這兩個檔案是順利復原所有資料,而不產生 -1216 錯誤所需要的第一個與最後一個記錄檔。所有資料庫最低的最後一致值就是低錨點記錄檔,而最高的最後一致值就是高錨點記錄檔。
    在上面範例中,低錨點記錄檔是 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:
    							
    一個記錄檔可能會回報數個簽章。第一個簽章一定是記錄檔本身的簽章;其他則是該記錄檔建立時正在執行的資料庫。在上面範例中,記錄在資料庫檔案中的記錄檔簽章確實和低錨點記錄檔中的記錄檔簽章相符。

    如果您無法找出低錨點記錄檔,就無法在該資料庫中向前顯示記錄檔。如果您無法找出低錨點記錄檔,也無法在任何資料庫中重新顯示任何記錄檔。您可以使用兩種方法來處理找不到低錨點記錄檔的問題:
    • 您可以移除所有的記錄檔。由於所有資料庫都一致,因此您可以在沒有任何記錄檔的情況下啟動資料庫,但您將無法復原尚未寫入資料庫檔案的資料。
    • 您可以移除具有最低的最後一致值的資料庫,直到可以從低至高錨點建構一系列未中斷的記錄檔,然後再執行剩餘資料庫的復原作業。當您將移除的資料庫放回儲存群組中後,便無法在這些資料庫中重新顯示其他的資料。
  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,標頭中不會有路徑資訊,因為記錄檔系列中的第一個記錄檔的標頭是在第一個資料庫附加至記錄檔之前產生的。在這個情況下,您必須查看下一個記錄檔的標頭以檢視資料庫路徑資訊。有時候,因為某個資料庫在記錄檔建立之後才建立或附加至記錄檔資料流,所以接下來的記錄檔可能也會發生同樣的情形,但這種情況很少見。
  5. 收集所有記錄檔,在序列未中斷的記錄檔中從低錨點記錄檔開始盡可能向前收集,然後將這些記錄檔複製到目前的交易記錄檔路徑。請勿在沒有事先備份檔案的情況下覆寫已經存在伺服器上的記錄檔。如果要執行此項操作,您可能要從多種備份媒體還原記錄檔。

    在上面範例中,低錨點是 E0002ac8.log 而高錨點是 E0002cc7.log。當您檢查可用的記錄檔時,可能會發現所找到的最高的編號記錄檔比必要的編號少一號 (例如,找到的是 E0002cc6.log,而不是 2cc7)。通常會發生這種情況是因為 E0n.log 尚未填滿,所以尚未重新命名為在序列中的編號。如果要判斷 E0n.log 實際上是否就是高錨點記錄檔,您必須使用下列命令來檢查記錄檔標頭中的 lGeneration 值:
    eseutil /ml E0n.log | find /i "lGeneration"
    下列是上述命令的輸出範例:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
    lGeneration:11463 (0x2cc7)
    							
    注意:如果要使用 Eseutil 公用程式來檢視記錄檔的標頭,請使用 /ml 參數;如果要檢視資料庫檔案的標頭,請使用 /mh 參數。如果您弄錯了參數,命令的輸出就不正確。

    一般來說,高錨點記錄檔也就是可用的最高編號的記錄檔,但如果符合下列情況,就不是這樣:
    • 記錄檔曾經受到毀壞。

      - 或 -
    • 您一次還原儲存群組中的所有資料庫。
    在第一種情況下,您很可能會在復原期間遇到 -1216 錯誤;在第二種情況下,您可以向前顯示記錄檔,甚至超過高錨點記錄檔,只要維持 lGeneration 序列即可。
  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 命令進行了三件事:檢查每個記錄檔是否損壞、報告連續的記錄檔序列中是否有任何中斷以及偵測不相符的記錄檔簽章。

    所有要重新顯示的記錄檔之間都必須要有相符的記錄檔簽章。在開始重新顯示之前,您必須移除所有簽章不相符的記錄檔。

    在您移除沒有通過驗證測試的檔案之後,此時 Transaction Logs 資料夾中剩下的交易記錄檔:
    • 會有連續的 lGeneration 編號序列,從低錨點記錄檔開始至少一直連續到高錨點記錄檔,如果有可能,還會繼續下去。
    • 會有相符的記錄檔簽章。
  7. 如果高錨點記錄檔尚未命名為 E0n.log,請重新命名。
  8. 從 System Path 資料夾移除 E0n.chk 檔。

    在沒有檢查點檔案的情況下,Exchange Server 會從 Transaction Logs 資料夾中可用的最低編號的記錄檔開始重新顯示記錄檔:低錨點記錄檔。如果有 E0n.chk 檔,Exchange Server 會從記錄在這個檔案中的檢查點開始重新顯示。如果 E0n.chk 所指的點超過低錨點記錄檔,還原的檔案組的重新顯示作業會完全失敗。在許多情況下,如果檢查點檔案有錯誤,您就必須重新開始從備份還原資料庫檔案。
  9. 在裝載儲存群組之前請做最後的檢查,確認:
    • 所有資料庫檔案都位於它們的執行路徑中。
    • 位於執行中交易記錄檔路徑中的記錄檔,只有從低錨點記錄檔開始至少一直連續到高錨點記錄檔的檔案,最高的可用記錄檔稱為 E0n.log。
    • System Path 資料夾中沒有 E0n.chk 檔。
    您現在應該可以順利的裝載儲存群組,並以這個檔案組開始重新顯示交易記錄檔。即使在完成還原及啟動資料庫之後,實際上仍然不一定可以還原所有記錄檔中的所有資料,因為重新顯示期間可能會發生資料庫簽章與路徑問題。本文的<處理資料庫簽章與路徑不相符的情形>一節會提供有關這些問題的詳細資訊。
  10. 如果資訊儲存庫尚未執行,請啟動資訊儲存庫,然後至少裝載儲存群組中的一個資料庫。這樣做可以對儲存群組中的所有資料庫執行軟修復。

    在舊版的 Exchange Server 中,在還原資訊儲存資料庫的離線備份之後,您通常還要執行 ISINTEG -patch 命令,以同步處理資料庫與目錄。當 Exchange 資料庫需要修補時,系統會自動執行修補作業,除非將資料庫還原至其他伺服器、儲存群組或邏輯資料庫物件,或是您曾經刪除資料庫的 Active Directory 物件,然後又在 Active Directory 中重新建立。在這些情況下,應用程式事件記錄檔中會記錄下列錯誤訊息。
    事件類型:錯誤
    事件來源:MSExchangeIS 信箱儲存區
    事件類別目錄:一般
    事件識別碼:1087
    日期:5/4/2001
    時間:8:33:42 PM
    使用者:N/A
    電腦: EXCHANGE1
    描述:The information store was restored from an offline backup.In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched. (從離線備份還原資訊儲存庫。在 Microsoft Exchange 系統管理員中,指出 First Storage Group\Private Information Store 資料庫允許還原,以便進行修補。)
    如果要解決這個問題,請在 Exchange 系統管理員、資料庫物件的 [資料庫] 內容中,按一下以選取 [此資料庫可被還原覆寫] 核取方塊。
檢查 Microsoft Windows NT 事件檢視器中的應用程式事件記錄檔,查看資料庫啟動時是否有任何錯誤或異常現象。每個重新顯示的記錄檔都會出現 301 事件。請注意還原過程中是否有錯誤與警告。

處理資料庫簽章與路徑不相符的情形

資料庫就像記錄檔一樣有自己的簽章。雖然記錄檔簽章在 E0n000001.log 檔建立之後就不會變更,但只要資料庫的實體拓樸有更改,資料庫簽章就會變更,並且不會透過記錄檔追蹤變更。使用 Eseutil 離線重組或修復資料庫會變更資料庫簽章。發生這種事件之後,資料庫可以和以前一樣附加至相同的記錄檔資料流,但資料庫不會重新顯示在擁有舊簽章時所執行的任何交易。而較舊的資料庫則不會重新顯示資料庫簽章變更之後所執行的任何交易。

由於這種情況會使資料庫簽章重設,因此建議您在離線重組或修復資料庫之後,立即製作資料庫的完整備份。如果您稍後還原具有舊簽章的資料庫,重新顯示作業可以順利的進行到簽章變更之處,但是會失去超過該處的所有變更。

如果在記錄檔資料流中間變更資料庫路徑,所產生的影響和變更簽章類似:重新顯示作業會在變更點中斷 (連線備份 API 提供在還原期間重新對應路徑的功能;因此,即使路徑在製作備份之後有所變更,連線備份 API 還是可以完整的重新顯示記錄檔)。

如果在重新顯示期間發生資料庫簽章或資料庫路徑的問題,應用程式事件記錄檔中會報告這些資料庫簽章或資料庫路徑問題,內容中還會包含每個記錄檔的 301 重新顯示事件。超過問題點的記錄檔可能看來順利顯示,但這只是因為系統沒有重複記錄同樣的不相符警告之故。一般的規則是,特定資料庫中的重新顯示作業,會在資料庫遇到的第一個資料庫簽章或路徑錯誤之處遭到截斷。

屬性

文章編號: 296788 - 上次校閱: 2007年12月3日 - 版次: 4.6
這篇文章中的資訊適用於:
  • 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及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。

提供意見

 

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