Microsoft Exchange Server 的設(shè)計考慮了備份因素。組織需要備份其郵件數(shù)據(jù)，同時還必須能夠恢復(fù)這些信息。為滿足這些要求，Microsoft 構(gòu)建了一整套數(shù)據(jù)保護選項，從傳統(tǒng)的備份和低端的恢復(fù)到操作連續(xù)性，直至可提供最高水平的可用性和災(zāi)難恢復(fù)功能的真正業(yè)務(wù)連續(xù)性解決方案。在本文中，我將介紹這些選項并幫助您決定如何為您的組織實施最佳 Exchange 恢復(fù)解決方案。

　　級別 1：基本備份和恢復(fù)

　　您可以在數(shù)據(jù)庫脫機后備份 Exchange 文件，也可以在數(shù)據(jù)庫正在運行時進行備份。實際上，更多情況下建議采用后一種方式來備份 Exchange。但 Exchange 不僅僅是一組文件。它是包含大型數(shù)據(jù)庫文件和事務(wù)日志的信息存儲區(qū)。發(fā)送給 Exchange 的郵件消息會立即記錄在事務(wù)日志中，當(dāng)系統(tǒng)進入某些空閑周期時(通常在若干毫秒之后)，這些消息將復(fù)制到數(shù)據(jù)庫中。Exchange 通過將信息盡快存儲到磁盤，來提供高水平的恢復(fù)功能?；謴?fù) Exchange 最根本的是這兩組信息的可用性。一旦系統(tǒng)出現(xiàn)故障，則需要結(jié)合使用上一次備份以及該備份點之后發(fā)生的所有事務(wù)，將 Exchange 恢復(fù)為最近的信息。注意，Exchange 會根據(jù)需要自動將事務(wù)重新播放到恢復(fù)的數(shù)據(jù)庫中。

　　備份程序訪問 Exchange 數(shù)據(jù)庫信息的方式是通過可擴展存儲引擎 (ESE) 備份 API 或更新的 VSS 解決方案(稍后我將介紹這些新的解決方案)。只要啟動 ESE 備份，Exchange 就會暫時掛起向其數(shù)據(jù)庫進行的所有寫入。在 ESE 暫時將數(shù)據(jù)庫設(shè)置為只讀模式以便能夠在完整備份過程中對其進行復(fù)制的同時，它還會使用一個臨時數(shù)據(jù)庫來保存在備份過程中發(fā)生的新事務(wù)。當(dāng)備份完成后，ESE 會將數(shù)據(jù)庫返回正常的讀/寫模式，并應(yīng)用累積在臨時數(shù)據(jù)庫中的事務(wù)。成功完成備份后，最后還會清除掉舊的事務(wù)日志。

　　即使對于在半夜時分備份正在進行時登錄的用戶，此備份過程也是直接和透明的;雖然如此，ESE 仍然需要很長時間才能完成，特別是因為 Exchange 數(shù)據(jù)庫的規(guī)模跨度很大，可以從幾千兆字節(jié)到可管理的 30 到 50GB，甚至高達 100GB——如果使用標(biāo)準(zhǔn)技術(shù)，幾乎一整夜也無法完成備份。要初步了解使用 NTBackup.exe 時的可用選項，請看一下圖 1。

　　

　　圖 1 使用 NTBackup 實用工具

　　Exchange 最佳實踐

　　如果希望能夠迅速從常見硬件和系統(tǒng)故障中恢復(fù)，應(yīng)在夜間運行完整的 Exchange 備份。為改進 Exchange 服務(wù)器使用本地磁盤時的性能和恢復(fù)能力，應(yīng)使用單獨的 RAID 陣列來存儲 Exchange 數(shù)據(jù)庫和 Exchange 事務(wù)日志，這一點很重要。這樣，如果 RAID 陣列控制器出現(xiàn)故障，或者如果陣列中的多個磁盤出現(xiàn)故障，使得剩余磁盤無法再重新構(gòu)造條塊化的數(shù)據(jù)時，您仍然能夠進行恢復(fù)。如果丟失了事務(wù)日志，您仍然可以在其他驅(qū)動器上獲得最新的 Exchange 數(shù)據(jù)庫，從而能夠繼續(xù)使用新事務(wù)日志進行正常操作。如果丟失了數(shù)據(jù)庫驅(qū)動器，此時的恢復(fù)策略應(yīng)是返回到前一夜的 Exchange 數(shù)據(jù)庫的完整備份，然后應(yīng)用當(dāng)前日期的事務(wù)日志使之保持最新狀態(tài)。

　　限制 Exchange 數(shù)據(jù)庫的大小非常重要，以便能夠以合理的用時備份每個數(shù)據(jù)庫——更重要的是，能夠進行恢復(fù)。對多數(shù)組織來說，這意味著需要使數(shù)據(jù)庫的大小保持在 30 到 50GB 之間。如果數(shù)據(jù)庫超出該大小，則建議將其拆分成多個小數(shù)據(jù)庫，以便能夠?qū)謴?fù)進行管理。

　　備份和恢復(fù)連續(xù)性

　　數(shù)據(jù)庫和事務(wù)日志的放置位置非常重要——不僅僅是對于備份性能，還事關(guān)恢復(fù)速度。今天，所有服務(wù)器都支持各種級別的磁盤驅(qū)動器冗余(稱為 RAID)。從基本上講，RAID 使得磁盤驅(qū)動器出現(xiàn)故障時不會導(dǎo)致系統(tǒng)崩潰，但在更換和重建磁盤之前系統(tǒng)性能會降低。在此期間，為響應(yīng)每個磁盤的訪問請求，陣列控制器必須動態(tài)地使用剩余磁盤重新構(gòu)建數(shù)據(jù)。有關(guān)郵箱服務(wù)器存儲設(shè)計的詳細信息，請參閱 Microsoft IT Showcase 文章“Exchange Server 2007 的 64 位應(yīng)用”。

　　Exchange 的核心功能是其單實例數(shù)據(jù)庫設(shè)計。這意味著在一個 Exchange 數(shù)據(jù)庫中，只會存儲一個特定郵件消息副本以及一個附件(如果有)。如果該郵件是發(fā)送給同一信息存儲區(qū)中的多個收件人，則會創(chuàng)建指向相應(yīng)對象(郵件、附件)的附加指針，但不會復(fù)制對象。這不僅對提高傳送效率很有好處，還可以為 Exchange 節(jié)省磁盤和磁帶空間。

　　由于 Exchange 只擅長恢復(fù)整個數(shù)據(jù)庫，因而單個郵箱、文件夾或郵件的恢復(fù)會要求先恢復(fù)整個磁帶。毫無疑問，用戶會希望具備更小單位的恢復(fù)能力。磁帶的這種單實例特性使之非常難以實現(xiàn)。針對此需求，備份服務(wù)供應(yīng)商采用了“程序塊級備份”(Brick-Level Backup) 技術(shù)(本人并不建議采用此技術(shù))。使用認可的 ESE 備份 API 完成 Exchange 的完整備份后，備份產(chǎn)品會將每個郵箱添加到備份磁帶上。因為該備份 API 并未提供一種從單個郵箱中提取數(shù)據(jù)的方式，所以使用了 MAPI。結(jié)果，備份磁帶由于復(fù)制了所有郵件和附件而變得非常長。

　　Microsoft 提供了一些增強功能，可部分解決這一問題。例如，管理廢紙簍(或轉(zhuǎn)儲程序)會在用戶將某些數(shù)據(jù)刪除后，將其保留一段時間，以防再次需要。此外，不再需要保留一個備用服務(wù)器作為 Exchange 恢復(fù)林;恢復(fù)存儲組允許管理員部分裝載從磁帶上取回的已恢復(fù)數(shù)據(jù)庫，并將數(shù)據(jù)復(fù)制或合并至郵箱級別。

　　熟能生巧

　　許多組織都曾領(lǐng)教過一項艱巨的任務(wù)，即不管決定在哪個級別上進行備份和恢復(fù)，都必須定期對備份媒體和恢復(fù)過程進行測試。許許多多管理員都是在災(zāi)難發(fā)生后才知道其備份技術(shù)和恢復(fù)過程是否能夠正常工作。最佳的測試時間是在建立和配置了嶄新的服務(wù)器之后，當(dāng)它已經(jīng)開始作為 Exchange 組織的一部分運行，但上面只有很少的用戶時即開始。此時，您應(yīng)當(dāng)執(zhí)行一次 Exchange 完整備份，并定期備份您的驅(qū)動器，此外還要捕獲系統(tǒng)的狀態(tài)，其中包括系統(tǒng)磁盤上的重要文件和 IIS 元數(shù)據(jù)庫(其中存儲了 Exchange 的路由配置)。然后，小心地重新格式化該新服務(wù)器并重新啟動，更新最初構(gòu)建服務(wù)器時獲取的注釋。您應(yīng)當(dāng)能夠從系統(tǒng)狀態(tài)中恢復(fù)設(shè)置，同時還要具有足夠的文檔來手動重新實施系統(tǒng)配置的設(shè)置。

　　在這種“消防演習(xí)”上花些時間可顯著減少將來的恢復(fù)操作所需的時間。您應(yīng)當(dāng)定期重復(fù)此過程。執(zhí)行此任務(wù)時，可記下從離站位置獲取磁帶所需的時間。那些在此期間不得不耐心等待的用戶經(jīng)常會開始認真考慮磁盤到磁盤備份在其備份和恢復(fù)策略中所能起到的重要作用——即使離站磁帶存儲仍然為災(zāi)難恢復(fù)提供了最終支撐。

磁帶備份面臨的挑戰(zhàn)

　　從磁帶中恢復(fù)需要很長時間?，F(xiàn)在，Exchange 對于組織來說是如此重要，以致于用戶和管理者希望它能夠始終處于可用狀態(tài)。當(dāng)出現(xiàn)嚴(yán)重問題時，大多數(shù)組織都感到措手不及。沒有人會想到從磁帶中恢復(fù) 75GB 的數(shù)據(jù)庫居然需要八個小時——而這甚至還未包括從離站存儲設(shè)施中獲取磁帶或重新安裝操作系統(tǒng)所需的時間。

　　此外，從磁帶中檢索正確的數(shù)據(jù)庫也是一項嚴(yán)峻的挑戰(zhàn)。自從 Exchange 首次面世以來的 10 年時間里，磁盤存儲和廣域網(wǎng)的成本已經(jīng)有了大幅下降。這使得許多組織能夠支付更快的備份和恢復(fù)方法的成本。這些組織可以利用相關(guān)技術(shù)，為其 Exchange 基礎(chǔ)結(jié)構(gòu)實現(xiàn)操作的連續(xù)性和災(zāi)難恢復(fù)功能。

　　級別 2：操作連續(xù)性

　　操作連續(xù)性是一組旨在使恢復(fù)過程盡可能迅速完成，同時盡量縮短意外停機時間的過程和技術(shù)。操作連續(xù)性針對通過磁帶進行的本地恢復(fù)提供了改進的恢復(fù)時間目標(biāo) (RTO) 和恢復(fù)點目標(biāo) (RPO)。它力爭消除(只要有可能)使磁帶重新入站所需的時間。請參見圖 2 以比較備份和恢復(fù)的操作連續(xù)性與災(zāi)難恢復(fù)。

　　

　　圖 2 恢復(fù)連續(xù)性 (單擊該圖像獲得較大視圖)

　　該圖顯示了恢復(fù)和可用性的連續(xù)性，左下角的技術(shù)速度慢、成本低;右上角的技術(shù)速度快、成本高;同時在操作連續(xù)性與災(zāi)難恢復(fù)解決方案之間有意進行了一下模糊過渡。

　　該圖揭示了這些方法在成本、恢復(fù)時間和可用性之間的取舍狀況。在本文中，我會刻意將本地連續(xù)性處理與災(zāi)難恢復(fù)明確區(qū)分開來。災(zāi)難恢復(fù)始終被視為一種遠程操作，并以使數(shù)據(jù)離站為主要目標(biāo)。距離帶來了額外難度，并且通常成本更高，但災(zāi)難恢復(fù)是有關(guān)嚴(yán)重災(zāi)難性事件后的業(yè)務(wù)繼續(xù)的措施。稍后我將深入探討這一問題。

　　一些歷史

　　隨著 Exchange 在基礎(chǔ)結(jié)構(gòu)中的地位越來越重要及其數(shù)據(jù)庫中存儲的信息越來越多，顯然有必要減少備份和恢復(fù)所需的時間。某些大型組織與 Microsoft 協(xié)同工作，開發(fā)出一種方法，大大改進部分操作的恢復(fù)。如果某個組織可以從外界接收或向其發(fā)送新電子郵件，則表面上看起來好像什么也沒有發(fā)生。畢竟，表面現(xiàn)象是很重要的。

　　為實施 Exchange 的這種“撥號音”式恢復(fù)，一個新的空數(shù)據(jù)庫取代了被破壞的數(shù)據(jù)庫。然后，Exchange 和 Active Directory® 使用適當(dāng)?shù)臋?quán)限創(chuàng)建新郵箱，使得用戶能夠發(fā)送和接收郵件。當(dāng)檢索了備份磁帶并恢復(fù)了數(shù)據(jù)后，可使用管理權(quán)限進行裝載。然后，Exchange 管理員可以將恢復(fù)的郵箱合并到撥號音郵箱中?？筛鶕?jù)需要劃分郵箱的優(yōu)先級。雖然這是一項改進，但該過程很耗時，也比較復(fù)雜;它最初使用了 EXMERGE，后來應(yīng)用到了恢復(fù)存儲組中。不過應(yīng)當(dāng)注意，撥號音恢復(fù)方案之后的完整數(shù)據(jù)恢復(fù)會是一項非常艱巨、復(fù)雜的任務(wù)(尤其是在 Exchange 2007 中，存儲組可多達 50 個)。如果考慮實施撥號音恢復(fù)方案，請注意確保益處大于付出。

　　卷影復(fù)制服務(wù)

　　為利用低廉的磁盤并從生產(chǎn) Exchange 服務(wù)器中消除處理器開銷，針對 Microsoft® Windows Server® 2003 和 Exchange 開發(fā)了一個新備份 API。所創(chuàng)建的卷影復(fù)制服務(wù) (VSS) 旨在提供一致的數(shù)據(jù)時點副本。這些快照是可迅速生成的 Exchange 數(shù)據(jù)的只讀副本，其中只連續(xù)包含發(fā)生更改的數(shù)據(jù)。這些副本通常指向另一個具有可用磁盤空間的服務(wù)器，或者指向存儲區(qū)域網(wǎng)絡(luò) (SAN)。可以保留多個快照，并在磁帶上制作備份。這樣一來，生產(chǎn) Exchange 服務(wù)器將不再受到備份軟件和磁帶副本開銷的性能影響。

　　使用 VSS 進行 Exchange 數(shù)據(jù)保護具有多個優(yōu)點。首先，可以從 Exchange 服務(wù)器中消除磁帶備份操作的性能負載。雖然仍然需要備份到磁帶，但它可以使用 Exchange 數(shù)據(jù)的副本，而不影響用戶性能。其次，每晚多次獲取快照成為可能。隨之而來的另一個好處是您可以在輔助服務(wù)器上或其他本地存儲中保留多個快照。

　　市場上有許多第三方產(chǎn)品利用了 VSS 快照功能。有些產(chǎn)品只是減少了備份和恢復(fù) Exchange 數(shù)據(jù)庫所需的時間，另一些產(chǎn)品還添加了某些功能，例如比本機 Exchange 所能提供的單位更小的恢復(fù)能力，使您能夠恢復(fù)至郵箱級別。雖然沒有人喜歡如此零碎的備份，但人們確實希望能夠恢復(fù)特定的文件夾，甚至單個郵件消息。

　　復(fù)制技術(shù)

　　以軟件為媒介的 Exchange 故障轉(zhuǎn)移是某些復(fù)制供應(yīng)商提供的一個選項。它將激活一個備用 Exchange 服務(wù)器，然后通知 Active Directory 所有用戶的郵箱已經(jīng)移走。有兩種方式來完成此任務(wù)，并且它們都要求對 Exchange 和 Windows 環(huán)境進行某些自定義。一種需要對 DNS 用一些小技巧，使得備用服務(wù)器能夠獲取故障服務(wù)器的名稱和 IP 地址。這種方法的優(yōu)點是客戶端工作站方面會比較簡單，因為 Outlook® 會認為它仍在使用相同的服務(wù)器。

　　第二種方法使用一臺運行 Exchange 的備用服務(wù)器，其上存儲了數(shù)據(jù)庫的副本，但并未進行任何裝載。出現(xiàn)故障時，該備用服務(wù)器將通知 Active Directory 所有用戶的郵箱已移到它那里。然后將運行一個腳本或發(fā)布一個組策略，告知客戶端它們位于不同的郵件服務(wù)器上。Outlook 2007 能夠識別 Active Directory，這使得該過程變得更簡單，因為它自己就會自動識別出這些映射。

　　使用 MSCS 的本地群集

　　可用性連續(xù)性的高端是 Microsoft 群集服務(wù) (MSCS);Exchange 是能夠識別群集的應(yīng)用程序。群集可在兩臺或更多臺計算機之間共享信息，這樣如果其中一臺出現(xiàn)故障，其他計算機可接管其工作。今天，大多數(shù) Exchange 群集都有兩個或四個節(jié)點，最多可以使用八個節(jié)點。始終會指定一個節(jié)點作為被動節(jié)點——可在 Windows Server 正在運行且安裝了 Exchange Server 的情況下操作，但沒有活動的郵箱。Exchange 2003 提供了一種兩節(jié)點的主動/主動群集，但是由于性能負載的原因，現(xiàn)在不建議使用它，Exchange 2007 將不再對其提供支持。

　　針對 Exchange 2003 的群集方式，包含一個被動節(jié)點的 Exchange 2007 群集仍然可以使用一個單一的共享存儲陣列。雖然群集品質(zhì)的存儲陣列通常具有許多冗余功能來防范多種類型的故障，但它們?nèi)匀恢惶峁┮粋€數(shù)據(jù)副本，這留下了一個隱患。這就是為什么這些群集被稱為單副本群集 (SCC) 的原因，以區(qū)別于 Exchange 2007 中的多副本群集 (MCC) 所帶來的下一代數(shù)據(jù)保護手段。我們將在說明災(zāi)難恢復(fù)時進一步討論 MCC。

　　本地連續(xù)復(fù)制

　　本地連續(xù)復(fù)制 (LCR) 是 Exchange 2007 的一項新功能，它提供了一種改進方式來維護同一服務(wù)器內(nèi) Exchange 數(shù)據(jù)庫和事務(wù)日志的第二份副本。這為使 Exchange 數(shù)據(jù)庫和事務(wù)日志分別位于不同 RAID 陣列中的最佳實踐添加了一個冗余層：利用 LCR 可以在存儲數(shù)據(jù)庫主副本的陣列中存儲一份日志的輔助副本，然后在存儲日志主副本的陣列中存儲一份數(shù)據(jù)庫的輔助副本(參見圖 3)。如果其中任何一個 RAID 控制器或陣列本身出現(xiàn)故障，您仍然可以使用另一個陣列中的數(shù)據(jù)庫和事務(wù)日志。通過這種方式，您可以繼續(xù)操作——雖然這會令人感到有些緊張，并且性能會有所降低——直至能夠?qū)⒊霈F(xiàn)故障的陣列重新建立起來。

　　

　　圖 3 配置 LCR

LCR 是一種本地操作連續(xù)性解決方案，而不是一種備份方案，因此您仍然需要一個完整備份策略。使用 LCR 還有一個性能損失，因為您的服務(wù)器現(xiàn)在要制作數(shù)據(jù)庫和事務(wù)日志的兩份副本。此外，在 Exchange 2007 的實現(xiàn)中存在一些限制，使得 LCR 只適用于較小的組織，因為 LCR 只支持某個存儲組中的一個數(shù)據(jù)庫，以及某個組織中的一個公用文件夾數(shù)據(jù)庫。

　　使用 LCR 恢復(fù)功能實現(xiàn)的故障轉(zhuǎn)移不是瞬間即可完成的——必須要由一位有經(jīng)驗的 IT 專業(yè)人士通過運行腳本來備份 Exchange。該過程要求執(zhí)行在 Exchange 管理控制臺之外運行的 Exchange 命令行管理程序命令。

　　Exchange Server 2003 Enterprise Edition 使組織最多能夠運行 20 個 Exchange 數(shù)據(jù)庫(四個存儲組，每組最多五個數(shù)據(jù)庫)，而 Exchange 2007 Enterprise Edition 允許使用多達 50 個存儲組，每組都有自己的數(shù)據(jù)庫。事務(wù)日志也從 Exchange 2003 中的 5MB 文件減少為 Exchange 2007 中的 1MB 文件。這兩項變化都是設(shè)計來支持 LCR 的——外加群集連續(xù)復(fù)制 (CCR)，它在某種程度上也與此相關(guān)。

　　中小型組織將使用 LCR 以便為其 Exchange 操作提供改進的數(shù)據(jù)保護。LCR 易于實現(xiàn)，但仍然需要手動干預(yù)。作為一種“同一服務(wù)器/本地磁盤”解決方案，LCR 只是邁向改進的操作連續(xù)性的第一步。雖然它確實能夠針對 RAID 陣列和 RAID 控制器的故障起到保護作用，但多個磁盤或 RAID 控制器同時發(fā)生故障的可能性是很低的。多數(shù)情況下，故障方案涉及整個服務(wù)器的崩潰，這將我們引向了 Exchange 保護中的下一步。

　　第三方本地非主機復(fù)制

　　為進一步提升 Exchange 的恢復(fù)能力，第三方供應(yīng)商開發(fā)了一些利用“非主機”復(fù)制方式的產(chǎn)品，使用 Exchange 日志文件在另一臺計算機上保留一份 Exchange 數(shù)據(jù)庫的備用副本。在這種情況下，數(shù)據(jù)保護或歸檔解決方案將執(zhí)行一個 Exchange 的 ESE 完整備份，將其備份到另一臺計算機上，然后在 Exchange 關(guān)閉事務(wù)日志時立即將其取出。它會將這些事務(wù)日志插入到其 Exchange 數(shù)據(jù)庫副本中，以使其始終保持最新狀態(tài)。如前所述，這些日志很小(在 Exchange 2003 中為 5MB，在 Exchange 2007 中為 1MB)，因此當(dāng)完整備份完成后，將這些日志文件復(fù)制到非主機服務(wù)器上幾乎不會給 Exchange 服務(wù)器帶來任何系統(tǒng)開銷。

　　級別 3：災(zāi)難恢復(fù)和高可用性

　　災(zāi)難恢復(fù)是指在主要數(shù)據(jù)中心不可用時將它重新建立起來并恢復(fù)運行的能力。Exchange 需要具備有效的災(zāi)難恢復(fù)能力，因為電子郵件和日歷功能在今天已經(jīng)成了許多組織的命脈。

　　有些公司將其傳統(tǒng)的離站存儲磁帶備份作為某種形式的災(zāi)難恢復(fù)措施，但是如果您唯一的數(shù)據(jù)中心遭到火災(zāi)或水災(zāi)破壞，那么即使用車?yán)瓉沓删淼拇艓б埠翢o意義。災(zāi)難恢復(fù)實際上不僅僅是將數(shù)據(jù)移到另一處位置，還涉及恢復(fù)應(yīng)用程序并使之運行的技術(shù)和過程。要實現(xiàn)有效的災(zāi)難恢復(fù)，需要讓主系統(tǒng)和輔助系統(tǒng)相隔一定距離。地點相隔距離的遠近取決于考慮要克服的災(zāi)難的量級。如果您擔(dān)心失火，那么或許園區(qū)內(nèi)的另一棟建筑已足夠遠。但是，涉及火車或飛機失事的基礎(chǔ)設(shè)施災(zāi)難可能會影響 1 英里或 1 英里以上的半徑范圍。許多災(zāi)難是區(qū)域性的：洪水、冰雹、地震甚至停電等。通信也可由于自身的災(zāi)難而陷入困境——從切斷與您的 ISP 之間的鏈接的反鏟問題到拒絕服務(wù)攻擊，直至針對一般商務(wù)的 Internet DoS 攻擊。

　　在實踐中，如果您的組織已經(jīng)在多個地點配備了 IT 員工，那么針對您要防范的災(zāi)難類型，其中一處位置可能會符合您的遠程操作連續(xù)性標(biāo)準(zhǔn)。與求助于災(zāi)難恢復(fù)服務(wù)提供商或在新位置租用空間相比，使用自己的設(shè)施和員工要更經(jīng)濟。

　　災(zāi)難恢復(fù)的終極目的是給人一種感覺：使客戶確信您的業(yè)務(wù)仍在運行中。當(dāng)災(zāi)難襲擊某個城市或地區(qū)時，人們對此可以理解;但是如果您的公司在幾天到一個星期之內(nèi)沒有恢復(fù)正常，那么很有可能客戶和供應(yīng)商會做出最壞的猜想;許多公司都因此而落敗下去。對于客戶來說，您的運營必須看上去已經(jīng)恢復(fù)正常，以使他們確信您的業(yè)務(wù)仍在繼續(xù)?？蛻魧謴?fù)的及時性存在不同認識：與辦公家具供應(yīng)商的暫停運營相比，他們對金融服務(wù)公司的暫停運營更易失去耐心，這很容易理解。

　　災(zāi)難恢復(fù)要求

　　如果希望能夠在災(zāi)難后使 Exchange 重新在線，需要將其數(shù)據(jù)復(fù)制到一個輔助地點，并使用適當(dāng)復(fù)制技術(shù)將數(shù)據(jù)提供給一個已準(zhǔn)備好運行這些數(shù)據(jù)的預(yù)熱 Exchange 服務(wù)器，然后通知 Outlook 客戶端它們的郵箱已經(jīng)移走。

　　Exchange 在復(fù)制方面的要求較高，尤其是在距離較遠時。對于真實的事務(wù)數(shù)據(jù)庫，每個寫入的順序極為重要。使問題變得更加復(fù)雜的是，Exchange 使用 SMTP 傳輸協(xié)議在服務(wù)器之間傳輸所有事務(wù)和系統(tǒng)信息，而這是一種非常占用帶寬的協(xié)議。此外，對于 Exchange 群集，必須每隔 500 毫秒在系統(tǒng)之間傳遞一個檢測信號。如果輔助節(jié)點沒有收到該信號，則可能會觸發(fā)故障轉(zhuǎn)移。

　　解決這些問題的復(fù)雜性或許是 Microsoft 直到今天才在 Exchange 2007 中涉足這一領(lǐng)域的原因。在 Microsoft 尚未涉足之前，若干第三方解決方案已經(jīng)開發(fā)出來，它們使用基于主機或基于陣列的復(fù)制功能來復(fù)制 Exchange 數(shù)據(jù)。

　　供應(yīng)商意識到他們可以通過將節(jié)點分散到不同位置來擴展一個群集，這稱為擴展群集。今天，要實現(xiàn)擴展群集，最常見的方式是使用通用的第三方數(shù)據(jù)復(fù)制產(chǎn)品或那些專門為擴展 Exchange 節(jié)點而開發(fā)的產(chǎn)品。您可以使用 MSCS 完成此任務(wù)，但 WAN 上的子網(wǎng)要求是個難點。向遠程數(shù)據(jù)中心提供可靠的高帶寬連接是很復(fù)雜的，再加上群集，無疑會增加建立、維護和定期測試災(zāi)難恢復(fù)系統(tǒng)的成本，并會提出更高的人員要求。

　　群集連續(xù)復(fù)制

　　Microsoft 通過 Exchange 2007 中的群集連續(xù)復(fù)制功能擴展了它對群集的支持。CCR 擴展了 LCR 的功能，現(xiàn)在能夠維護兩個 Exchange 數(shù)據(jù)庫和事務(wù)日志副本，在兩個群集節(jié)點上實現(xiàn)同一設(shè)想。災(zāi)難恢復(fù)意味著需要使主系統(tǒng)與輔助系統(tǒng)在地理上彼此分離，在 Windows Server 2008(原代號為“Longhorn”)使得擴展群集成為可能之前，Microsoft 多副本群集 (MCC) 無法跨越很遠的距離。

　　使 MCC 節(jié)點能夠具有單獨的數(shù)據(jù)副本的技術(shù)稱為多數(shù)節(jié)點集 (MNS)，它是指一個選舉過程，其中兩個或多個節(jié)點決定由誰來保存數(shù)據(jù)的活動副本。當(dāng)出現(xiàn)故障時，其余節(jié)點將進行一次新選舉以確定由誰接管作為新的主處理/數(shù)據(jù)服務(wù)器。支持這種技術(shù)民主行為的是 CCR，它將確保每個節(jié)點都具有最新的數(shù)據(jù)庫。使用 CCR 的 Exchange 2007 群集被限制為只有兩個節(jié)點。

　　在大型組織中，Exchange 服務(wù)器通常在服務(wù)器上配置本地系統(tǒng)磁盤，然后通過 SAN 連接到 Exchange 數(shù)據(jù)庫(使用 SCSI、光纖或 iSCSI 磁盤陣列)。對于 MCC/MNS 群集，一個有趣的問題是高端的 Exchange 存儲是否會退化到為每個節(jié)點使用本地 RAID 陣列。如果 MNS 群集的目的是使每個節(jié)點具有自己的獨立存儲，那么將每個節(jié)點指向旨在提供公共存儲的 SAN 是否仍然有意義呢?

　　在一個中規(guī)中矩的 MCC/MNS 群集方案中，主節(jié)點會將存儲放在 SAN 上，而輔助群集節(jié)點會使用本地磁盤或成本較低的 iSCSI SAN。該輔助節(jié)點可遠離主數(shù)據(jù)中心，位于一個不具有 SAN 基礎(chǔ)結(jié)構(gòu)的遠程位置。

　　不管其如何展開，使用 MNS 和 CCR 的 MCC 都是在冗余和增強的可用性方面取得的另一項進步，因為此時有多臺計算機能夠進行故障轉(zhuǎn)移，并且數(shù)據(jù)在單獨的存儲元素上進行復(fù)制。不過，在 Windows Server 2008 出現(xiàn)之前，這仍然完全局限在一個數(shù)據(jù)中心內(nèi)。Windows Server 2008 將提供擴展群集的本機支持，使 MNS 群集中的節(jié)點能夠在地理位置上相隔任意遠的距離——前提是節(jié)點之間的網(wǎng)絡(luò)延遲能夠穩(wěn)定地低于 500 毫秒。直到這時(以及從此以后)，第三方群集技術(shù)才能基于 Microsoft MNS 和 CCR 提供擴展群集所需的地理分隔，以便獲得有效的災(zāi)難恢復(fù)解決方案。

　　群集屬于災(zāi)難恢復(fù)連續(xù)性的高端領(lǐng)域，而 CCR 可恰當(dāng)?shù)囟ㄎ粸?Exchange 的高可用性功能。即使這種結(jié)合具有較高的成本和人員要求，但對于希望獲得一個同構(gòu)的 Microsoft 環(huán)境的用戶來說，這將是一種令人興奮而先進的解決方案。

　　第三方遠程操作連續(xù)性

　　一旦面世，Microsoft 解決方案和第三方擴展產(chǎn)品就將占據(jù)災(zāi)難恢復(fù)連續(xù)性的絕對高端，這一點勿庸置疑。數(shù)秒內(nèi)即可自動完成故障轉(zhuǎn)移——幾乎盡善盡美。不過，并非所有公司都需要如此級別的可用性和業(yè)務(wù)連續(xù)性，有些也無力為此支付數(shù)十萬美元的費用。對許多公司來說，能夠在幾分鐘內(nèi)完整恢復(fù) Exchange 的可靠解決方案已經(jīng)足以提供他們所需的所有操作連續(xù)性。

　　例如，Mimosa Systems, Inc. 將一個數(shù)據(jù)中心內(nèi)的操作連續(xù)性擴展到遠程連續(xù)性。在遠程位置，Mimosa DR 維護了一個 Exchange 副本，使用來自主 Exchange 服務(wù)器的事務(wù)日志使其保持最新狀態(tài)，并時刻準(zhǔn)備著將此有效副本提供給您的備用 Exchange 服務(wù)器。遠程 Exchange 服務(wù)器使用標(biāo)準(zhǔn)服務(wù)器硬件，并且就像單數(shù)據(jù)中心實現(xiàn)一樣，您可以使其保持預(yù)熱狀態(tài)，時刻準(zhǔn)備著在出現(xiàn)災(zāi)難時激活。一旦發(fā)生災(zāi)難，遠程位置的操作員可以啟動故障轉(zhuǎn)移并執(zhí)行故障轉(zhuǎn)移，包括裝載備用數(shù)據(jù)庫文件以及重新映射郵箱和 Outlook 配置文件。但是需要注意，這種第三方解決方案存在一定的支持局限，知識庫文章“Microsoft 針對修改或提取 Exchange 數(shù)據(jù)庫內(nèi)容的第三方產(chǎn)品的支持策略”對此進行了定義。

　　總結(jié)

　　Exchange 數(shù)據(jù)保護提供了一系列技術(shù)和過程，根據(jù)成本和功能性可將其分組為三個級別。開始考慮 Exchange 數(shù)據(jù)保護的要求時，您應(yīng)當(dāng)考慮利益相關(guān)者所能接受的停機時間。優(yōu)異的性能和快速的恢復(fù)要求付出更高成本，高端選項都將超過六位數(shù)。更經(jīng)濟的解決方案旨在努力提供更高水平的可用性，但無法達到最高水平。您應(yīng)根據(jù)自己組織的需要進行選擇。

Service Pack 1 for Exchange 2007