Exchange使用正常的恢複無法恢複的問題

來源:互聯網
上載者:User

標籤:exchange使用正常的恢複無法恢複的問題

                                Exchange使用正常的恢複無法恢複的問題

因為在Windows2003上安裝的Exchange2007是32位的測試版本,所以在進行還原的時候在所有設定和步驟都正確的情況下依然無法正常還原.目前經過一天的摸索,使FileMon進行檔案的追蹤的時候發現檔案沒有問題.經過反覆嘗試.終於發現了問題的所在,現提供解決思路供參考:

 

 

1 首先在沒有備份資料前,先開啟C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group目錄,查看目錄下包含的檔案:

650) this.width=650;" title="210829997.jpg" alt="wKioL1PNDYTzGs1xAAI-dSE1HWY563.jpg" src="http://s3.51cto.com/wyfs02/M00/3F/FD/wKioL1PNDYTzGs1xAAI-dSE1HWY563.jpg" />

(如果沒有這些檔案,那麼你的恢複一定會失敗,請查看這些檔案是否齊全.)

下面可以嘗試裝入資料庫,這時候會有相應的報錯提示如:

下面可以嘗試裝入資料庫,這時候會有相應的報錯提示如:

如所示,共有E0000000001.log到E000000009.log的9個檔案,這些都是Exchange的初始資料庫資訊.同時注意觀察,目錄中還存在一個E00.chk檔案,這個檔案是這裡非常重要的一個檔案,它可以稱為一個檢查點檔案.

這個檔案預設情況下只能通過cmd命令提示字元的方式來進行查看,我們通過eseutil工具 + 生產力來查看E00.chk檔案的具體內容.操作方法如:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/211134115.jpg" />

修複完成後,開始掛載資料庫,如:

從可以看出,當前的CheckPoint(檢查點)檢查到的是 E0000…9.log檔案.而Fullbackup(完全備份)的起始檔案還是0檔案.這說明什麼呢?這說明目前的系統還沒有進行備份工作.

那麼這裡我們要多瞭解的一點是在Exchange2003中記錄檔都是使用5M為一個單位進行儲存.而到了Exchange2007中為了提高效率將記錄檔大小都改為了1M,那麼為了驗證記錄檔確實是記錄了郵件的內容,我們來使用OWA給administrator自己發送幾封測試郵件.接受到測試郵件的OWA如:

650) this.width=650;" style="width:649px;height:380px;" border="0" src="http://img1.51cto.com/attachment/201205/211507745.jpg" width="643" height="380" /> 

這時候我們回到剛才的資料庫的存放目錄,查看一下記錄檔的情況,如:

如果遇到其他問題,推薦使用Filemon軟體,該軟體支援對於檔案變動的追蹤.一般比較方便發現問題.

有寫的不對的地方還請各位多多指教!!!

有寫的不對的地方還請各位多多指教!!!

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/211705512.jpg" width="654" height="345" /> 

通過可以發現在目錄中出現了E00000…A.log的記錄檔,這個檔案也就是用來記錄我們剛才我們產生的兩封郵件資訊的.

這時候再此通過Eseutil工具 + 生產力來查看一下E00.chk檢查檔案的狀態.如:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/212012838.jpg" width="657" height="340" /> 

通過可以發現CheckPoint檢查點已經變為了0xA的樣子了.說明狀態已經變到了E000…A.log的日誌狀態了.

下面我們使用Ntbackup來進行一下備份工作.備份中不需要做任何特殊操作,按照提示進行即可.備份完成後如:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/212258255.jpg" /> 

備份完成後,我們使用Eseutil.exe進行檢查點檔案的查看.發現檢查點檔案,和完整備份的起始位置都沒有變化.如所示,這時候還原是無法完成的.(估計原因是因為2007對於硬體設定較高,同步速度較慢的問題)

650) this.width=650;" style="width:649px;height:336px;" border="0" src="http://img1.51cto.com/attachment/201205/212456117.jpg" width="666" height="336" />

這時候重要的一步到來了.請你重新啟動你的Exchange2007服務.

(當然,如果你的時間很充裕,不妨去抽袋煙,等上半小時,也會有奇異的效果出現).

在經過漫長的等待後,哇塞,終於可以登陸了.我們再使用eseutil工具 + 生產力查看一下檢查點檔案,如:

 

 

首先徹底刪除郵件.如所示:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/212812156.jpg" />

注意觀察,Fullbackup的內容已經從0x0變為了0xC的表示方法

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/213703477.jpg" />

下面使用NTbackup工具進行還原作業,操作如,選擇正確的備份資料資訊.

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/214056917.jpg" />

(注意啦,這裡為了保證成功率,可以單擊”工具”—“編錄一份待命資料庫檔案”,然後確定.)

開始還原,還原的時候如做選擇即可.

開始還原,還原的時候如做選擇即可.

然後就可以卸載資料庫了.請如所示操作:

為了保險起見,我們再來備份一下郵箱的資料.(當然這步可能是多餘的,但是時間原因,沒有仔細想,建議可以嘗試一下).在備份以後,Exchange會將備份過的記錄檔自動刪除掉.這個時候,再來查看一下Exchange的資料庫的內容.如:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/213041714.jpg" width="471" height="190" /> 

從可以看出之前存在的從表面上看A到C的檔案全部消失了.而多增加了E0000..10.log和E0000…11.log的檔案.這時候我們可以再查看一下檢查點檔案,如:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/213312399.jpg" /> 

已經變為了0x10和0x11.好了,下面我們來看恢複的操作.

首先徹底刪除郵件.如所示:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/213520989.jpg" />

接著開啟Exchange管理主控台,找到郵箱伺服器角色,做如下操作:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/213848693.jpg" />

下面使用NTbackup工具進行還原作業,操作如,選擇正確的備份資料資訊.

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/214056917.jpg" />

(注意啦,這裡為了保證成功率,可以單擊”工具”—“編錄一份待命資料庫檔案”,然後確定.)

開始還原,還原的時候如做選擇即可.

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/214236265.jpg" />

完成還原後,我們來c:\temp7目錄下看一下,可以看到如下資訊:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/214432616.jpg" />

這裡的檔案代表要使用resotre.env來恢複E0000…F.log和E0000….10.log的日誌資訊(這兩個日誌中恰好記錄的就是之前的郵箱資訊的變動情況.)

(如果沒有這些檔案,那麼你的恢複一定會失敗,請查看這些檔案是否齊全.)

下面可以嘗試裝入資料庫,這時候會有相應的報錯提示如:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/214619950.jpg" /> 

中提示了544的報錯資訊,這證明伺服器的資料庫狀態有問題,需要使用工具 + 生產力eseutil來進行修複.修複方法如:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/214816437.jpg" />

從可以看出來當前的狀態是未完成狀態,所以需要使用eseutil /p的命令進行修複,這裡的過程省略.

修複完成後,開始掛載資料庫,如:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/215026689.jpg" />

掛載完成後,再次使用OWA登陸,出現如的結果:

650) this.width=650;" border="0" src="http://img1.51cto.com/attachment/201205/215215227.jpg" />

經過總結髮現,最主要的原因可能是伺服器的相應不是很及時,這是32位版本存在的一個比較明顯的問題,在實際生產環境中還沒有發現此類問題.在實驗中應加以注意.

如果遇到其他問題,推薦使用Filemon軟體,該軟體支援對於檔案變動的追蹤.一般比較方便發現問題.

有寫的不對的地方還請各位多多指教!!!

Exchange使用正常的恢複無法恢複的問題

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.