Exchange Server 軟恢複和硬恢複介紹

 當使用Microsoft Exchange Server 2003的時候，必須注意recovery (恢複)和restore (還原)之間的區別。還原是指將資料庫和記錄檔還原到伺服器上的動作，恢複是指重放交易記錄到恢複過的資料庫中的動作。

　　有兩種形式的恢複：

　　軟恢複 在當資料庫意外停止後被重新載入時的日誌重放過程，或當交易記錄被重放到資料庫的離線備份中。

　　硬恢複 交易記錄重放過程發生在從線上備份恢複資料庫後。

　　軟恢複

　　在預設的軟恢複情境中，外部的事件意外終止了Exchange 伺服器資料庫，但是資料庫和記錄檔保持完好無損並仍在原來的位置。當資料庫被重新載入的時候，Exchange閱讀檢查點檔案，並開始重放被列在檢查點日誌中的交易記錄。如果沒有檢查點檔案存在的話，重放從儲存群組中交易記錄檔夾中最老的可用記錄檔開始。

　　Exchange 伺服器將它們寫到資料庫中，完成那些記錄檔中發現的還沒有被寫到資料庫中的事務。Exchange 伺服器從來不會將事務寫進資料庫檔案中直到所有的操作組成的整體被安全放置到記錄檔中。您不需要在資料庫中物理地撤消或收回一個事務，當重放開始的時候如果所有的未提交的交易記錄還在這時意外中止出現。

　　重要訊息：軟恢複過程的一個基本的假設是，由於故障或在故障之後，沒有資料庫或記錄檔被管理員移動、刪除或損壞。

　　如果您從重播序列中刪除任何需要的交易記錄，Exchange 伺服器軟恢複將立即失敗。如果需要的日誌丟失的話，您必須要麼從舊的日誌執行恢複，從資料庫的備份(一個不需要那些日誌副本)中還原，要麼您必須使用Exchange 伺服器資料庫工具(Eseutil.exe)來修複這個資料庫。

　　交易記錄檔重播的一些基礎規則

　　交易記錄檔重播的一些基礎規則有下面一些：

　　1. 您不能將記錄檔從一個資料庫重播到另一個資料庫中。記錄檔內部的操作是低層級的。您無法看到記錄檔裡面的東西像“傳遞郵件A到郵箱B”。記錄檔操作的一個好的例子是“在資料庫頁面7890上寫123位元組的流到位移量456位元組”。

　　想像您要編輯一個文檔給出一些指令，您的指令是“在第五頁第四段的第三個句子中的第二個單詞後插入 '將是或將不是'”。如果這些指令被應用到文檔而不是您打算的地方，結果是將隨機地損壞該文檔。同樣地，如果錯誤的記錄檔被重播到一個Exchange 伺服器資料庫中，類似的結果將發生。Exchange 伺服器因此必須有多個安全機制來阻止這樣的損壞發生。如果您修複或整理Exchange 伺服器資料庫，以前和該資料庫關聯的交易記錄不能在被重播到它裡面。

　　如果您嘗試重播日誌在完全整理或修複之後，Exchange 伺服器跳過這些不正確的交易記錄。再一次考慮類似文檔編輯。如果一個段被移動、編輯或刪除由於指令被建立，應用到期的指令將具有毀壞性因為將它們變成了一個完全不同的文檔。

　　2. 您不能重播記錄檔除非所有未提交的記錄檔從資料庫上次啟動並執行時候是可用的。您必須讓所有的記錄檔從檢查點開始並且在那個時間資料庫被備份。接著您才能從該點重播記錄檔只要它們不存在中斷的序列。如果中間或序列的開始有單個檔案丟失的話，重播將停在那裡。

　　3. 您不能重播記錄檔如果資料庫檔案已經被移動到不同的檔案路徑(在Exchange 2000 Server SP2之前)。該限制不會應用如果您正在使用Exchange 2000 Server SP2 或後續版本，因為Eseutil.exe 處理重播即使路徑已經發生更改。下面的部分將具體描述重播過程是如何工作的。

　　4. 您不能重播記錄檔如果檢查點指向了錯誤記錄檔。Exchange 伺服器對待檢查點日誌好象它是第一個可用日誌並忽略所有舊的記錄檔。如果您還原了資料庫的舊檔案備份，檢查點將回到以前很遠，Exchange 伺服器嘗試從一個很新的記錄檔開始重播。您能夠解決該問題通過刪除檢查點檔案，這樣強制Exchange 伺服器掃描所有可用的記錄檔。(如果您恢複一個線上備份，硬恢複將忽略檢查點檔案。)

　　5. 您不能重播記錄檔如果儲存群組的任何資料庫檔案已經被刪除。所有的以前正在啟動並執行突然出現意外出現終止的資料庫必須存在，這樣才能保證軟恢複成功。該限制能夠被克服通過使用Eseutil.exe 來運行軟恢複。

　　如果一個儲存群組中的其他資料庫正在運行軟恢複這時一個資料庫丟失了，以後的日誌重播將變的比較複雜。通過軟恢複失敗，Exchange 伺服器給管理員一個機會來分析情況並決定是否不通過資料庫來處理。

　　進階軟恢複情境

　　在大多數情況中，運行軟恢複的最好的方法是在一個儲存群組中載入任何一個資料庫。因為一個儲存群組中的所有資料庫共用同一個記錄檔流，軟恢複發生在整個儲存群組層級而不是單個資料庫層級。

　　在一些特定的環境中，使用Eseutil.exe運行軟恢複有好處。下面的情境是最通用的執行個體。

　　1. 您想恢複一個遺失資料庫的儲存群組。

　　2. 您想恢複一個“超出空間”的單獨資料庫而不影響其他的資料庫或儲存群組的記錄檔。

　　Eseutil.exe 軟恢複功能的完整文法，列出了所有可能的開關如下：

　　ESEUTIL /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i

　　例如，在命令列中，輸入下面的命令：

　　ESEUTIL /r e01 /Lf:/mdbdata /sc:/exchsrvr/mdbdata /dg:/mdbdata /i

　　注意：Eseutil.exe 命令列參數不是大小寫敏感的，它們被混合在一起在上面的例子中為了避免混淆"L" 和 "I" 字元。

　　該例子說明了儲存群組資料庫恢複，記錄檔的首碼是E01，記錄檔位於f:/mdbdata，檢查點檔案位於c:/exchsrvr/mdbdata，資料庫和流檔案位於g:/mdbdata，丟失的資料庫被忽略(因為末尾的/i開關)。

　　運行軟恢複的最小Eseutil.exe 命令列是：

　　ESEUTIL /r Enn

　　如果從提示中設定交易記錄目錄該命令才會生效。您應該知道下面這些當使用Eseutil.exe來運行軟恢複：

　　1. 如果您不指定任何檔案路徑在命令中，Eseutil.exe 使用您當前的命令列目錄作為記錄檔和檢查點檔案的預設的目錄。

　　2. 資料庫檔案不一定必須在記錄檔路徑中。記錄檔記錄資料庫路徑，因此Eseutil.exe 發現所有的資料庫路徑通過閱讀記錄檔。使用/D開關來覆蓋儲存在記錄檔中的路徑只有當您確定記錄檔的路徑是不正確的。

　　3. 如果檢查點檔案不與交易記錄檔在相同的路徑，所有被掃描的記錄檔都要重播，而不是從檢查點開始重播。您能夠臨時拷貝一個已經存在的檢查點檔案到記錄檔路徑。在軟恢複完成之後，Exchange 不在使用檢查點的副本在正常的資料庫操作中。如果檢查點檔案中的資訊是不正確的，軟恢複將失敗但是不會損害資料庫。您能夠嘗試在恢複在刪除檢查點檔案或找到正確的檢查點檔案。檢查點檔案對成功運行恢複來說不是最根本的，但它能夠節省大量的時間如果您有大量的記錄檔。

　　如果您想開始恢複當一個資料庫從儲存群組丟失，您能夠使用下面的命令：

　　ESEUTIL /r Enn /i

　　/i 開關意味著忽略丟失的資料庫。如果您使用該開關然後載入丟失的資料庫，Exchange 伺服器提示您建立一個新的資料庫。如果您打算恢複舊資料庫在一些點，您將不能重播新的資料到它裡面。您現在有同一個邏輯資料庫的兩個單獨的版本。

　　這種情況，儲存群組中一個資料庫已經被一個空的資料庫替換，是恢複儲存群組能夠協助的那種。您能夠載入額外的資料庫在恢複儲存群組中，並使用郵箱合并嚮導(ExMerge.exe)來增加一個資料庫的內容到其他的資料庫。

　　如果您想開始恢複“超出空間”來恢複一個資料庫而不影響儲存群組中的其他資料庫，您應該建立一個新的空檔案夾並移動您想恢複的資料庫檔案，您想重播的交易記錄，和檢查點檔案(如果需要)到該路徑。該路徑一定不能包含其他的資料庫檔案。

　　在您將資料庫和日誌一起隔離到一個檔案夾，運行下面的命令從那個檔案夾：

　　ESEUTIL /r Enn /i /d

　　通過使用/d 開關而不指定路徑，您能夠覆蓋記錄檔中的資料庫路徑。此外，由於該檔案夾沒有其他的資料庫可用，您隱藏了伺服器上其他資料庫從這個特定的恢複過程。

　　如果您沒有正確使用/d參數，恢複過程能夠影響伺服器上其他的資料庫。即使在最壞的情況下，恢複過程將不會損壞其他資料庫。然而，恢複可能失敗在您正在工作的資料庫上。該恢複操作甚至可能影響其他資料庫以後的日誌重播能力。

　　注意：增加錯誤的可能性因為命令列變的更加複雜。作為一個總體的原則，當使用Eseutil.exe 的時候在命令中最小化指定的路徑資訊。在這種情況下，切換到記錄檔所在的目錄並在您的系統路徑中包含/exchsrvr/bin 目錄。

　　要運行軟恢複，重播序列中最後記錄檔必須命名為Enn.log 。如果最後的記錄檔已經被關閉並計數，您必須重新命名它在軟恢複成功之前。這個要求並不意味著當前的Enn.log 檔案已經被損壞，您能夠忽略它，並重新命名以前的日誌在Enn.log 序列中。在Exchange 2000 伺服器中，資料庫頭中的Logs Required 列出了恢複必須的最小數量的日誌，從檢查點日誌開始並連續到當前的日誌。在早期版本的Exchange 伺服器中，儘管沒有Logs required 值存在來強制要求的日誌存在，恢複仍會失敗如果需要的最後一個日誌沒有找到。Exchange 2000 伺服器和後續版本之間的唯一區別是恢複將在日誌重播結束的時候失敗而不是在開始的時候。

　　硬恢複

　　硬恢複必須完成在從線上備份還原後。硬恢複是有點類似軟恢複的日誌重播過程，但是有一些重要的不同之處。在硬恢複中，這些不同包括：

　　1. Patch資訊必須應用到資料庫在記錄檔重播期間。

　　2. 檢查點檔案被忽略。使用Restore.env 而不是檢查點來決定恢複應該從哪個記錄檔開始。

　　Exchange 伺服器5.5 管理員可能比較熟悉過程註冊表中的還原。Restore.env 替換了Exchange 2000 伺服器中那個鍵的功能。您能夠查看Restore.env 檔案的內容通過運行Eseutil /cm 命令。

　　1. 如果資料庫已經被還原到一個和以前備份時不同的路徑，記錄檔重播成功，忽略列在記錄檔中的資料庫路徑。

　　2. 還原的交易記錄檔在正常的交易記錄檔夾restore. Log檔案也有可能被重播之前先從管理員指定的臨時檔案夾重播。

　　3. 硬恢複不會失敗如果儲存群組中的其他資料庫丟失的話。

　　從線上備份組還原的資料庫檔案(.edb and .stm)被還原到指定的資料庫正常路徑。還原通過覆蓋現有的資料庫檔案開始。如果有機會在將來您可能需要現有的資料庫檔案，您必須移動它們或備份它們在從線上備份還原之前。考慮線上備份的還原可能會因為其他原因而失敗。即使在那時現有資料庫檔案不能啟動，它們仍可能被修複，如果需要的話資料仍可以被利用。

　　當您開始線上備份還原時，Exchange 伺服器提示您提供一個臨時檔案夾位置。備份程式還原交易記錄從備份組到該位置，而不是到正常的交易記錄檔路徑。備份程式也在臨時檔案夾中建立Restore.env 檔案。

　　硬恢複中的Restore.env 的功能類似於軟恢複中的檢查點檔案。Restore.env 定義應該出現在臨時檔案夾中用於硬恢複的交易記錄檔的範圍。如果您放置了額外的日誌在臨時檔案夾-它們超出了Restore.env 中列出的範圍-它們不會被重播並且恢複進程可能會自動刪除它們。

　　您也許有不在線上備份組中的額外的記錄檔要重播。在這種情況下，將這些日誌放置到儲存群組的正常交易記錄檔夾而不是臨時檔案夾。在硬恢複完成從備份組中重播日誌還原之後，該進程檢查正常的交易記錄檔夾來看序列中的下一個日誌是否可用。

　　注意：如果您還原到備用的伺服器，或您已經刪除並重新建立了原來的資料庫，只有臨時檔案夾中的交易記錄被重播。正常資料庫檔案夾中的交易記錄不會被重播。該特徵是避免交易記錄重播引起衝突萬一Exchange 伺服器知道還原的資料庫與備份的不同。在這種情況下還原的資料庫稱為“刪除的”資料庫。

　　您能夠為刪除的資料庫播放額外的交易記錄通過將它們放置到臨時檔案夾中。在這種特殊的情況中，恢複過程不會刪除或忽略它們，而重播它們。如果您懷疑要還原的環境，將額外的交易記錄的副本同時放置到臨時檔案夾和正常資料庫檔案夾中。不管資料庫的刪除狀態，恢複過程將重播一個或其他日誌集。當您還原到恢複儲存群組，重播一樣生效就像您還原到源儲存群組。您能夠放置額外的日誌在恢複儲存群組資料庫檔案夾中，並且臨時檔案夾中的額外的日誌將被忽略和刪除。

　　例如，假設有6個記錄檔，E0000003.log 到 E0000008.log，從備份中還原到臨時檔案夾。在這些記錄檔已經被播放後，恢複現在檢查作業記錄檔案夾的屬於相同日誌序列的E0000009.log 檔案。記錄檔中的內部標記驗證它們為共同擁有。保持重播的決定只在記錄檔名稱的基礎上不會被執行。

　　如果記錄檔9找到的話，重播繼續只要序列中的下一個日誌是可用的。如果記錄檔9不存在的話，恢複過程建立一個名稱為E00.log的新記錄檔在臨時檔案夾中。該記錄檔只用於記錄資料庫中需要以一致狀態關閉它的更改。在這點上，資料庫被完全恢複。它自動重啟，並將儲存群組中最新的記錄檔附上。恢複過程接著刪除臨時目錄中的所有檔案。