通訊
Exchange Server 2007 的資料保護和嚴重損壞修復
Lee Benjamin
摘要:
- 基本備份及還原
- 資料的持續性
- 複寫技術
- 替代解決方案
Microsoft Exchange Server 的設計兼顧備份功能。組織需要備份其郵件訊息資料，也必須能夠還原該資訊才行。為了滿足這些需求，Microsoft 建置了一系列的資料保護選項，從基本的
備份和還原，到作業的持續性，到真正的業務持續性解決方案，以提供最高階的可用性和嚴重損壞修復功能。本文將探討這些選項，並幫助您決定如何為組織實作最佳 Exchange 復原解決方案。
第一層：基本備份及還原
您可以選擇在資料庫離線時備份 Exchange 檔案，也可以在資料庫執行時進行備份。事實上，後者是一般建議的 Exchange 備份方式。但 Exchange 不止是一組檔案而已。它是一個含有大型資料庫檔案和交易記錄檔的資訊儲存庫。傳送至 Exchange 的訊息會立即記錄在交易日誌檔中，當系統有一些空檔時 (通常只是晚幾毫秒而已)，訊息就會複製到資料庫本身。Exchange 讓資訊能夠儘快儲存到磁碟上，因而可提供非常高度的復原能力。還原 Exchange 的基礎，正是這兩組資訊的可用性。萬一系統故障，需結合先前的備份以及自備份時間點以後的所有交易，才能使 Exchange 還原到最新資訊。請注意，必要時，Exchange 會在還原的資料庫中自動重新執行那些交易。
備份程式存取 Exchange 資料庫資訊的方式，是透過可延伸儲存引擎 (Extensible Storage Engine，ESE) 備份 API 或較新的 VSS 解決方案，我會在稍後討論這些解決方案。每當起始 ESE 備份時，Exchange 會暫停其資料庫的所有寫入作業。同時，ESE 會暫時將資料庫設定為唯讀模式，使它可以在完整備份中進行複製，它也會利用暫時資料庫來保存備份期間進行的新交易。當備份完成時，ESE 會使資料庫回到其正常讀寫模式，並套用累積在其暫時資料庫中的交易。備份也會在成功備份程序結束時清除舊的交易記錄檔。
此備份程序的方式很直接，即時是半夜登入的使用者也無法察覺到備份的進行，ESE 可能要花費很長的時間才能完成，尤其是因為 Exchange 資料庫大小有可能從少數 GB 到可管理的 30、50、甚至到 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 復原樹系 (Recovery Forest)；復原儲存群組 (Recovery Storage Groups) 可以讓系統管理員局部裝載從磁帶還原的資料庫，以便在信箱層級進行資料的複製或合併。
熟能生巧
許多組織得到這樣的教訓：不論他們決定何種備份及修復層級，備份媒體和修復程序都必須定期測試才行。有太多系統管理員只有在嚴重損壞之後，才瞭解到他們的備份技術和還原程序是否真的有用。測試的最佳時機是在建置及設定全新伺服器之後的隔天，因為那時候它已成為 Exchange 組織作業的一部分，但只有少數使用者在使用。這個時候，您應該執行 Exchange 完整備份、磁帶機定期備份及擷取系統狀態，包括系統磁碟上的重要資料和 IIS Metabase (亦即儲存 Exchange 路由設定的位置)。然後冷靜地重新製作新伺服器的格式並重來一遍，然後在過程中更新您一開始建置伺服器時所做的筆記。您應該可以從系統狀態還原設定，但也有足夠的文件可手動重新實作系統設定。
您花在此「消防演習」的時間，將可大幅減少未來的復原時間。請定期重複此程序。當您在從事這項活動時，請計算從存放磁帶的遠端地點帶回磁帶花費了多少時間。對於那些歷經過漫長等待之煎熬的人，通常會開始嚴肅地思考磁碟到磁碟備份對於其備份及還原策略的重要性，即使繼續維持遠端地點磁帶儲存備份機制以提供嚴重損壞修復的支援。
磁帶備份的困擾
從磁帶還原需要花費太多時間。Exchange 對組織如此重要，使用者和管理階層都預期服務不會中斷。當嚴重問題發生時，大部分的組織都會慌張。因為沒有人可以接受需要花費八個小時才能從磁帶還原 75GB 的資料庫，而且那甚至還不包括從儲存磁帶的遠端地點取得和重新安裝作業系統所要花費的時間。
不僅如此，從磁帶擷取正確資料庫也是一項挑戰。從 Exchange 發行至今已經 10 年了，磁碟儲存和廣域網路的成本已大幅下降。因此，許多組織可以負擔得起更快的備份及還原方法。這些組織可以利用科技，來提升其 Exchange 基礎結構的作業持續性以及嚴重損壞的修復功能。
第二層：作業持續性
作業持續性是一組程序和技術，主要是要使復原作業儘快完成，使意外停機的時間縮至最短。作業持續性在磁帶式本機復原方面，改良了復原時間目的 (Recovery Time Objective，RTO) 以及復原點目的 (Recovery Point Objective，RPO)。可能的話，它會盡力縮減磁帶回站的時間。請看一下 [圖 2]，將作業持續性與備份及還原和 DR 做個比較。
圖 2** 復原持續性 **(按影像可放大)
本圖表說明復原和可用性的範圍，從左下方的慢速但較便宜範圍，到右上方的快速但更昂貴的範圍，在作業持續性與嚴重損壞修復解決方案之間則故意有一個模糊地帶。
此圖讓您了解這些方法的成本、復原時間和可用性之間的取捨和平衡。在本文中，我故意明顯的區分本機持續程序和嚴重損壞修復。DR 一律視為遠端，以從遠端地點取得資料為主要目的。距離會帶來更多的挑戰，通常費用也更為昂貴，但 DR 正是與發生災難事件之後的業務持續性息息相關。稍後我會更詳細討論這一點。
一些歷史背景
當 Exchange 變成基礎結構的較重要部分，以及儲存在其資料庫中的資訊越來越多時，顯然備份及還原時間需要縮減才行。在與 Microsoft 合作時，有些大型組織所提出的方法，是復原部分作業的好處。亦即，如果組織可接收及傳送新的電子郵件給外界，那麼看起來似乎什麼事也沒發生。畢竟，形象很重要。
為了實作 Exchange 的這種類似「以撥號連接備援」的還原方式，這些企業會設置新的空白資料庫來取代損壞的資料庫。然後，Exchange 和 Active Directory® 會建立具有適當權限的新信箱，讓使用者能夠傳送及接收郵件。擷取備份磁帶及復原資料之後，可以由系統管理員裝載。然後 Exchange 系統管理員會將還原的信箱合併到撥號信箱。信箱可依需要排列優先順序。雖然有所改進，但這是一個耗時而複雜的程序，它原本使用 EXMERGE，後來改為復原儲存群組。不過值得注意的是，在撥號復原之後要再進行完整資料還原時，會是一項艱巨而複雜的工作 (尤其是 Exchange 2007 最多可以有 50 個儲存群組)。如果您考慮要實作撥號復原，請確保所耗費的大量資源是值得的。
磁碟區陰影複製服務
為了利用較便宜的磁碟及消除實際執行之 Exchange 伺服器的處理器負荷，Microsoft® Windows Server® 2003 和 Exchange 開發了新的備份 API。所建立的磁碟區陰影複製服務 (Volume Shadow Copy Service，VSS) 是為了產生一致的時間點資料複本。這些快照集是 Exchange 資料的快速唯讀複本，其中只會持續包括已變更的資料。複本通常會指向另一個有磁碟空間可用的伺服器或是存放區域網路 (Storage Area Network，SAN)。其中可以保留多個快照集，並備份到磁帶上。因此，實際執行的 Exchange 伺服器不再受到備份軟體和磁帶複製負荷的效能影響。
使用 VSS for Exchange 資料保護有一些好處。第一，可從 Exchange 除去磁帶備份作業的效能負荷。雖然還是會備份到磁帶，但它可以使用 Exchange 資料的複本，而不影響使用者效能。第二，可更頻繁地擷取快照集，一個晚上不止一次。而且您可以在第二個伺服器或其他本機儲存裝置上，保留多個快照集。
市場上有許多協力廠商產品利用 VSS 快照集功能。有些只是減少備份及還原 Exchange 資料庫的時間，有些則增加功能，例如比原始 Exchange 更細微的復原功能，使您可以向下還原到信箱層級。雖然沒有人喜歡這種積木式備份，但是大家都希望能夠還原特定資料夾，甚至還原特定郵件訊息。
複寫技術
軟體調解式 Exchange 容錯移轉，是某些複寫供應商提供的一個選項。它會使待命的 Exchange 伺服器上線，然後告訴 Active Directory 所有使用者信箱都已移動。有兩種方式可達成此目的，兩者都需要對 Exchange 和 Windows 環境做一些自訂作業。一種方式是要對 DNS 施展一點技巧，使待命伺服器接管失敗伺服器的名稱和 IP 位址。此方式的優點是可以減少用戶端工作站的影響，因為 Outlook® 會認為它仍然使用相同的伺服器。
第二種方式是使用保有資料庫複本且執行 Exchange 的待命伺服器，但不裝載任何東西。當發生失敗時，待命伺服器會通知 Active Directory 所有使用者信箱都已移動。然後會執行指令碼或發佈群組原則，以告訴用戶端他們要使用不同的郵件伺服器。Outlook 2007 可以感知 Active Directory，這使得此程序更簡單，因為它會自動完成對應配置。
使用 MSCS 的本機叢集
可用性較高的是 Microsoft Cluster Services (MSCS)；Exchange 為叢集感知式應用程式。叢集會在兩部或以上的電腦之間共用資訊，因此萬一其中一部故障，其他電腦可以接管。現在，大部分 Exchange 叢集為兩個或四個節點，不過最多可使用八個節點。有一個節點一定會指定為被動，其中會執行 Windows Server 且已安裝 Exchange Server，但沒有作用中的信箱。在 Exchange 2003 中，可以有雙節點主動/主動叢集，但由於效能負荷的緣故，現在並不鼓勵使用這樣的叢集，所以在 Exchange 2007 中也不支援。
就像 Exchange 2003 叢集配置一樣，包含被動節點的 Exchange 2007 叢集仍然可以使用單一共用儲存陣列。雖然叢集的儲存陣列一般會有多重備援功能來因應各種類型的失敗，但它們仍然只提供一份資料複本，這是此配置的弱點。這就是為什麼這些叢集稱為單一複本叢集 (SCC)，以便與 Exchange 2007 的多重複本叢集 (MCC) 提供的下一個資料保護境界做區分。當我們探討嚴重損壞修復時，會進一步討論 MCC。
本機持續複寫
本機持續複寫 (Local Continuous Replication，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 伺服器的任何負荷。
第三層：嚴重損壞修復及高可用性
嚴重損壞修復是指萬一主要資料中心無法使用時，回復運作及執行的功能。Exchange 需要有效的嚴重損壞修復機制，因為電子郵件和行事曆功能，已是當下組織最重要的運作方式。
有些公司認為他們儲存在遠端的傳統磁帶備份，是一種嚴重損壞修復形式，但如果唯一的資料中心因火災或水災而遭到破壞，那麼就算有一卡車的磁帶也於事無補。嚴重損壞修復不止是要將資料移到另一個位置，還需要相對的復原技術和程序，使應用程式得以盡快回復運作和執行。為了發揮具體的效果，嚴重損壞修復有賴於以一段距離隔開主要和次要系統。兩地之間相隔多遠，視您要克服的嚴重損壞規模而定。如果您擔心火災，或許園區另一棟建築就夠遠了。不過，如果是火車或飛機基礎結構嚴重損壞，則可能影響半徑一公里以外的範圍。許多嚴重損壞是區域性的：水災、暴風雪、地震，甚至電力中斷。通訊管道也有可能發生問題，從挖掘工程切斷與 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 資料庫和交易記錄檔複本的功能，以在兩個叢集節點上實現相同的想法。嚴重損壞修復意味著主要和次要系統在地理上分隔兩地，而 Microsoft 多重複本叢集 (MCC) 要等到 Windows Server 2008 (以前的代號是 "Longhorn") 才能跨越長距離，實現延伸叢集的可能性。
讓 MCC 節點有不同資料複本的技術，叫作多數節點組合 (Majority Node Set，MNS)，這是指兩個以上的節點為決定由哪一方保存資料即時複本的投票程序。當發生失敗時，剩餘節點便握有新投票權，以決定由誰接管，成為新的主要處理/資料伺服器。支援此民主性的技術是 CCR，它會確保每一個節點都有最新的資料庫。使用 CCR 的 Exchange 2007 叢集僅限於兩個節點。
在大規模的環境中，Exchange 伺服器通常會在伺服器本身設定本機系統磁碟，然後利用 SCSI、光纖或 iSCSI 磁碟陣列，透過 SAN 連接到 Exchange 資料庫。使用 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 資料保護的需求時，您應該考慮共同關係人能夠容忍多少停機時間。效能越高、速度越快的復原解決方案，其成本也會越高，所需的高階選購配備，至少得花費數十萬美元。有比較負擔得起的解決方案，雖然有效，但無法達到最高的可用性。您的選擇應該反映組織的真正需求。
Exchange 2007 的 Service Pack 1
目前在 Beta 測試階段的 Exchange 2007 Service Pack 1 (SP1) 預定將包含系統管理員作夢寐以求的一些功能，包括 OWA 的增強功能、主控台的其他 GUI 功能等。
規劃復原解決方案的系統管理員特別感興趣的，應該是 Exchange 2007 SP1 還會包括第三個可用性解決方案，來與 LCR 和 CCR 互補：次要持續性複寫 (SCR)。這是一種折衷方案，Microsoft 希望這可以提供更大的復原能力，但無須涉及「高可用性」的複雜度。
SCR 將容許 Exchange 資料庫和交易記錄檔，複寫到不同於您信箱一般所在的 Exchange 伺服器上。SCR 目標可為本機或遠端，也可以是待命的 Exchange 伺服器或叢集。不過，SCR 並不需要叢集在任一位置，且它與 CCR 不同之處在於其目標是待命環境，且容錯移轉為手動程序。請注意，您仍然需要透過連線取得首次 (極大) 的複本，本質上為完整備份。您可能偶爾就需要執行如此的大規模複寫作業，因此必須知道它對網路會有什麼影響，就像 CCR 和協力廠商的解決方案一樣。我預期市場上將會大量採用 SCR 和 CCR，以及提供類似和更多功能的附加產品。
Lee Benjamin 經營的公司名為 ExchangeGuy Consulting Services，他的工作包括直接面對客戶並為 Microsoft Partners 提供建議。Lee 是全球最大 Exchange 使用者群組 ExchangeServerBoston 的主席，也是 BostonUserGroups 的董事。Lee 也是 Exchange 的 MVP、Microsoft 合格培訓講師，而且經常在擔任產業會議中的講者。
© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.