Exchange2003災難恢復- 轉自winos的lianggj

先給你們看一下之前保存的一個Exchange災難恢復的圖片.

200962211404252030

先介紹一下我的環境吧.
我只用兩臺PC.一臺作爲Exchange服務器,一臺作爲加入域的客戶端.
拓樸如下:

20096221141660764

我新建了些用戶,發些郵件,以及在公用文件夾上放些內容.

200962211415022268

200962211415014811

200962211415084987

災難恢復之前,必須先有備份集.備份集包括2個,一個是活動目錄的備份,一個是Exchange的備份.我直接用系統的備份工具來備份.
我把備份集直接保存到遠程服務器上.(主要是機器比如說硬盤壞了,我都還能恢復,如果保存在本機,怕備份集就沒有啦.)

200962211492886590

200962211493818569 

 200962211494632565

200962211495328681

200962211495984959

20096221150569595

這時候,比如說硬盤壞啦.所有數據都沒有啦.(如果沒壞,只是系統壞了.最好把Exchange的原始數據包括MDBDATA所有文件保存出來.)
替換損壞的硬件,這是是硬盤.
重新安裝操作系統.(我重裝了2003,計算機名隨機,再安裝了NNTP,SMTP,IIS等組件.IP我還是用之前的IP=172.16.1.1,重裝這個過程在這裏我就不貼圖了.)

200962213263741866

200962213263734409

接下來可以還原系統狀態數據,來恢復活動目錄啦,

我先把備份文件拿回到新做的服務器本地.

20096221328528496

重啓機器,按F8進入目錄服務還原模式來還原系統狀態數據

200962213281685394

進入桌面前會有個提示信息,不必理會,按確定.進入桌面

200962213294336445

200962213294328987

在安全模式下,調入運行,輸入ntbackup.啓動備份還原工具.
進行如下操作,

200962213454274188

200962213454266731

200962213454246907

開始還原.(這裏就需要的時間會久一點,因爲活動目錄數據即備份集本身就大)

20096221347246558

20096221347239100

20096221347219277

20096221347254845

關閉之前會提示讓你重啓計算機,那麼重啓機計算機(重啓計算機機可能會遇到指示一個或者多個服務無法啓動的錯誤,原因是,還原Windows的備份集時還同時還原了所重建服務器的原始註冊表,註冊表上包括了試圖要啓動尚未重新安裝的服務.)可忽略這些錯誤,完成啓動過程.

200962213475617701

200962213475615324

忽略以上錯誤.
看一下活動目錄的數據恢復沒有?

200962213504346974

這時候可以做Exchange的災難恢復.
在災難恢復模式中運行Exchange的安裝嚮導.(把Exchange的安裝光盤放進光驅)
在運行中輸入:<drive>:\setup.exe /disasterrecovery
我的光驅在 D盤.

200962213512187464

200962213512180006

中途提示,可用備份集還原數據庫,就完成了.

200962213514825792

因我的Exchange是打了SP2補丁的,所以我還要在災難恢復模式下安裝補丁.
歡迎向導--同意協議-災難恢復安裝.

200962213531542891

200962213531535434

更新補丁時也有提示信息.如下:

200962213535977833

200962213535970376

就完成更新了,可以還原Exchange的數據啦.

200962213543453729

打開運行.調出ntbackup文件,右鍵調出文件編錄.進行還原操作.

200962213553988369

200962213553980911

200962213553961088

200962213553996657

在ESE(Exchange Server的數據庫系統是由名爲Extensible Storage Engine(簡稱ESE)的數據庫引擎來管理)引擎加載數據庫文件時,它會檢查數據庫文件的一個特殊標誌位。這個標誌位保存了數據庫文件上次是否被正常關閉。這個狀態由“ Consistent”或“ Inconsistent”來表示。對於一個正常關閉的數據庫文件,所有在Log文件和內存中的內容都應該已經提交到數據庫文件中,只有在這個時候,數據庫纔會被標記爲“ Consistent”。有一點需要注意,在運行中的數據庫,它的狀態一定是“ Inconsistent”,因爲在Log文件中肯定還有沒提交到數據庫文件內容。對於一個已經關閉並且狀態被標示爲“ Inconsistent”的數據庫,並不意味着這個數據庫庫文件損壞了,“ Inconsistent”只是表示,還有未曾寫入到數據庫文件的內容保存在Log文件中。
打開CMD,進入數據庫目錄,使用eseutil -mh 命令檢查數據庫狀態,如果文件的狀態爲dirty shutdown ,就處不一至狀態,那麼需要用eseutil /p來對數據庫進行修復.

2009622140625542

2009622140634910

對郵箱存儲進行修復.

下面是對EDB進行修復.
先分析下EDB數據庫裏面保存的是什麼文件?
當郵件從MAPI協議的客戶端(通常是Microsoft Office中的Outlook)提交到數據庫後,郵件內容被保存在edb文件中。
會不會想到.
如果請求的郵件是保存在edb文件中的,那麼信件被直接打開後返回給用戶。如果被請求的信件保存在stm文件中(此信件是SMTP格式的)?怎麼訪問啊?
答案如下:Exchange Server數據庫引擎首先會做一個轉換,把stm文件中的數據格式轉換成MAPI可以識別的格式,然後再發送給客戶端。這個過程稱之爲“On-demand Conversion”。

20096221413140400

20096221413646019

20096221414010187

剛纔是EDB數據庫,現在是STM.
用戶使用SMTP/POP3客戶端(如Outlook Express, FoxMail等)跟郵箱連接。當SMTP協議向Exchange Server提交郵件時,郵件的內容被保存在stm文件中。
那會不會這樣的疑問.
當用戶使用POP3協議來讀取郵件時,如果被訪問的郵件位於edb文件中?怎麼辦?
同樣,一個從MAPI到Internet格式的轉化(“ On-demand Conversion”)也會在後臺悄悄的發生.來解決這問題.

20096221421682615

接着再對公用存儲.

20096221441072634

20096221441065176

20096221441045353

20096221443228650

20096221443221192

20096221443291369

20096221443236938

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章