我最近處理過一個需要對整個林根域進行恢復的情況。結構本身是相對比較簡單的，包含兩個域，一個空的林根以及一個包括所有用戶、計算機等的子域。其中也只有大約4000個用戶。

但存在兩個（幾乎是致命的）問題。首先，該組織在根域中僅僅建立了一個域控制器。第二，更不幸的是，那個域控制器已經有超過10個月沒有進行備份了。盡管根域控制器是一個RAID-5的磁盤配置，在同一天內，災難發生了而且驅動器里面有兩個掛掉了。

這種類型的配置可能是承襲了微軟在Windows 2000的早期所信奉的一種***做法。當時的建議是創建一個空的根域，這樣在子域名字被更改時，可以對其進行添加或者移除（不能在一個域被定義后再對其進行改名）。

這種方法沒有得到延續，但是，因為多個域林會有其它的復雜性：在一個交叉域組中恢復組和用戶之間的后端鏈接，在全局目錄服務器只讀上下文中存在的延遲對象，以及其它的相關問題。為了避免這些問題，一些組織不得不把多域結構拆為單域。

在這個例子中，兩個域分別為Corp.com和EMEA.Corp.com，其中Corp-DC1是根域中的域控制器，而EMEA-DC1和EMEA-DC2為子域中的域控制器。

請注意，所有的客戶——包括用戶、工作站以及服務器——沒有被這個問題所影響，這使得我們有時間去指定并頒布一個處理計劃。

挑戰

這種情況下有若干問題和挑戰，包括：

• 我還沒有見過林根域需要被恢復的例子，并且我也找不到誰見過
• 恢復10個月以前的備份會在工作良好的子域控制器的林中引入延遲對象
• 當恢復1月份的備份時，在根域控制器中修改系統時間的話會遇到什么問題？
• 是否需要對Corp.com和EMEA.corp.com兩個域之間的信任關系進行修復？同樣地，是否需要重置安全隧道密碼？
• 是否有必要使用一個授權的備份？
• 當還原Corp.com 1月份的備份時，會遇到什么樣的復制問題？

盡管如此，在這次災難中也有一些正面的因素：

• 在根域中沒有用戶或者工作站——僅僅包括管理賬戶和域控制器。因此，當還原10個月以前的備份時，延遲對象的危害很小。
• 沒有對根域控制器進行過任何修改（比如活動目錄對象）（盡管需要關注配置容器的更改）
• 域名服務器被委托給子域。因此，對于客戶而言，EMEA.corp.com是域名獨立的，而且在父域中沒有資源。

恢復計劃

最初的想法是將EMEA域控制器恢復到1月份的備份，還原Corp域的域控制器，前滾子域控制器，然后調整到當前時間。這個20步的處理過程需要停機若干天，并且因為其復雜性和破壞性被駁回了。

我們***采用了下面這種更簡單的計劃：

1. 還原兩個子域控制器的當前備份（以及根域控制器1月份的備份），將三個域控制器變為一個私有網絡上的三臺計算機。
2. 解決問題，然后重復生產林的步驟。
3. 在Corp.com域中添加第二個域控制器。
4. 備份兩個域中的所有域控制器。

整個過程花費了大概3周時間，大部分的時間都用在研究日志、進行還原等等上面。我們對該過程進行了詳細的考慮，并有條不紊的對其進行實施，以確保任何事情都能合適地完成。另外，用戶不會遇到停機。這意味著，盡管沒有根域，林看起來岌岌可危，對于用戶認證和我們進行的還原，它都運作良好。我們進行的生產恢復是在不影響用戶的情況下，在上班時間里進行的。

恢復過程

恢復過程包括下面的步驟：

1.獲取三臺計算機，并在私有子網上對其進行配置。

2.在測試計算機上重建EMEA-DC1和EMEA-DC2上當前系統的狀態備份。

3.將Corp-DC1 1月份的備份還原到測試計算機。

4.將Corp-DC1的1月份備份上的系統時間設為當前的日期/時間。 

5.將墓碑生命期設為365（***）以消除暫時的延遲對象問題。通過ADSIEdit修改cn=Directory Service,cn=WindowsNT,cn=Services,cn=Configuration, dc=pp上的墓碑生命期屬性

6.將注冊表鍵嚴格復制一致性（strict replication consistency）的值設為“1”（嚴格），以避免復制過程中的延遲對象。

HKEY_LOCAL_MACHINE/System/CurrentControlSet/
Services/NTDS/Parameters
ValueName = Strict Replication Consistency
Data Type = Reg_DWORD 
Value Data =1

7.取消檢查Corp-DC1上的全局目錄參數。在復制完成后再重新啟用。  

8.使用HPSReports對域控制器進行體檢。逐個檢查出現的任何錯誤，直到所有錯誤都得到了清理：

• Netdom Trust/verfy，以驗證Corp和EMEA域之間的信任關系。

  C:>netdom trust Corp /domain:EMEA.corp.com /verify 

  The trust between Corp and EMEA.corp.com has been successfully verified.

• Repadmin/Replsum /bysrc /bydest /sort:delta，以對林中所有域控制器的復制進行測試。
• DCDiag /test:DNS /e /v，以測試林中所有DNS NS的DNS問題。
• 所有的事件日志。
• 確保應用程序事件日志顯示組策略（the Application event log indicating Group Policy）中的1704（SCECLI）事件都得到應用。同時，檢查每個機器的GPResult輸出以檢查GPO是否正常。
• 確保您可以通過一個Corp.com賬戶登錄到EMEA域的一個計算機 – 并可以反過來進行 – 以進一步的驗證信任關系。
• 將生產EMEA域中的客戶添加到測試EMEA域，并查看是否能被識別。
• 在每一個域中的域控制器里添加用戶和站點，并查看它們是否能復制到所有的域控制器。這對域進行了測試并對NC復制進行了配置。

9.當所有的問題都得到解決后，在生產林中重復這些步驟。 

10.在生產根域控制器（Corp-DC1）被還原以后，在那個域中設立第二個域控制器（根域中的第二個域控制器能防止最開始遇到的問題的產生）。 

11.對所有的4個域控制器有計劃的進行備份。

12.將墓碑生命期屬性重置為最小的120到180天。確保嚴格復制一致性（the strict replication consistency）的值仍為1。

結果

最初，在事件日志中顯示了大量的錯誤和警告，在Repadmin/showrepl報告中也有一些錯誤。其中很多錯誤是因為試圖修復系統而發生的。在運行一夜之后，大部分的錯誤都自己得到了修復。我們接下來對剩余的事件進行了處理，直到它們都得到解決。測試和生產環境產生了相似的結果。

1.因為沒有啟用動態注冊，會存在一些DNS問題。結果是我們不得不手動的對一些DNS記錄進行配置。

2.在對根域的Corp-DC1域控制器進行最初的還原之后（從舊的備份），可以在目錄服務事件日志中找到一個事件分類，包括：

• 1869 – 在Site-LAN（指的是EMEA-DC1）中發現了GC
• 1655 – 不能在其中一個站點（指的是EMEA-DC）中找到GC
• 事件1869和1655是按EMEA和Corp-DC1服務器的順序記錄的
• 一些1311事件。
• 一些涉及DNS查找失敗的復制不成功

許多1869和1865事件是在查找全局目錄時遇到了困難。對所有的這些事件置之不理，復制仍然可以進行，我們可以通過運行Repadmin /replsum /bysrc /bydest /sort:delta來發現這一點：

3.通過DCDiag /test:DNS /e /v報告，我們發現DNS按照預期進行工作。

4.存在許多W32時間事件 – 事件ID為29、24和22 – 不需要采取進一步的措施，就會隨著時間而消失。

5.在舊的被還原后的Corp-DC1被放到線上之后，最初會有大量的警告和錯誤事件。12個小時后，它們都自己得到了修復。

總的來說，還原工作進行得相當好，并且相對沒有差錯。這是在沒有停機時間，而且環境風險極小的情況下得到完成的。不必使用授權備份，并且信任關系也不需要被修復。由于我們已經在測試環境中進行了測試，所有我們有信心將這個計劃放到生產環境中。盡管如此，這對您只是“這應該可行”的一個假設，直到嘗試過您才可能真的對其進行掌握。

【編輯推薦】

1. Windows Server 林功能級別詳解
2. 系統運維枯燥生活中的那一絲快樂
3. FreeBSD 系統管理員都應該知道的那點秘密