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

　　級別 1：基本備份和恢復

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

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

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

　　

　　圖 1 使用 NTBackup 實用工具

　　Exchange 最佳實踐

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

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

　　備份和恢復連續性

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

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

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

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

　　熟能生巧

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

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

磁帶備份面臨的挑戰

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

　　此外，從磁帶中檢索正確的數據庫也是一項嚴峻的挑戰。自從 Exchange 首次面世以來的 10 年時間里，磁盤存儲和廣域網的成本已經有了大幅下降。這使得許多組織能夠支付更快的備份和恢復方法的成本。這些組織可以利用相關技術，為其 Exchange 基礎結構實現操作的連續性和災難恢復功能。

　　級別 2：操作連續性

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

　　

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

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

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

　　一些歷史

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

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

　　卷影復制服務

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

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

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

　　復制技術

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

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

　　使用 MSCS 的本地群集

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

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

　　本地連續復制

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

　　

　　圖 3 配置 LCR

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

　　使用 LCR 恢復功能實現的故障轉移不是瞬間即可完成的——必須要由一位有經驗的 IT 專業人士通過運行腳本來備份 Exchange。該過程要求執行在 Exchange 管理控制臺之外運行的 Exchange 命令行管理程序命令。

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

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

　　第三方本地非主機復制

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

　　級別 3：災難恢復和高可用性

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

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

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

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

　　災難恢復要求

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

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

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

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

　　群集連續復制

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

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

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

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

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

　　群集屬于災難恢復連續性的高端領域，而 CCR 可恰當地定位為 Exchange 的高可用性功能。即使這種結合具有較高的成本和人員要求，但對于希望獲得一個同構的 Microsoft 環境的用戶來說，這將是一種令人興奮而先進的解決方案。

　　第三方遠程操作連續性

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

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

　　總結

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

Service Pack 1 for Exchange 2007