選擇 SharePoint Server 的災害復原策略
適用於：
2013 Subscription Edition 
SharePoint in Microsoft 365
我們對「災害復原」的定義是能夠在裝載 SharePoint Server 伺服器陣列的主要資料中心無法繼續運作時，復原到正常狀態。 不論事件的性質與成因為何，資料中心運作中斷是非常嚴重的情況，必須採取貴組織的災害復原計劃中所定義的行動。 這表示要運用未受事件波及的資料中心裡的電腦資源，將能夠完整運作的伺服器陣列投入正式運作行列。
SharePoint Server 2019、2016、2013 和支援它們的 SQL Server 提供組態和內容復原選項，可符合復原時間目標 (RTO) 和恢復點目標， (發生災害時，您企業所需的 RPO) 。 如需這些與其他災害復原概念的詳細資訊，請參閱 SharePoint Server 的高可用性與災害復原概念。
簡介
SharePoint Server 伺服器陣列的有效災害復原策略必須能夠滿足貴組織的業務需求，這通常以兩個量值來表示：目標復原時間 (RTO) 和目標復原時點 (RPO)。 RTO 和 RPO 需求是在判斷災害發生時對組織造成的停機成本後所得出。
重要事項
[!重要事項] 以最佳作法而言，建議您在開發復原策略及實作技術解決方案之前，先清楚找出並量化貴組織的 RTO 和 RPO。 請將重點放在需要達成的目標，而非達成的方式。
產業之間和產業內的停機時間成本有很大的差異，特別是因為停機的影響不同。 業務大小是最明顯的因素。 不過，這不是唯一的一個。 設定量值表示建立失敗的本質和含意。 降低到最簡單的層級，重大應用程式的失敗可能會導致下列類型的損失：
應用程式服務中斷。 停機影響依應用程式和業務而有所不同。
資料遺失。 因系統運作中斷而遺失資料，可能造成嚴重的法律與財務影響。
大部分的組織都會因為上述兩種類型的損失而產生停機成本，但企業的性質會決定哪種類型的損失會造成最大的影響。 下列文章由 Chris Preimesberger 在 eWEEK 撰寫，強調數據中心停機的財務影響。 非計劃性的 IT 停機時間每分鐘可能會花費 $5000 美元：報告。
在大多數情況下，當資料中心停止運作的程度足以構成災害時，SharePoint 產品是少數幾個必須復原的應用程式之一。 基於這個理由，我們並未包含災害復原規劃的相關信息，但著重於確保您可以在另一個位置復原 SharePoint Server 伺服器數位的選項。
不論災害的類型和規模為何，復原過程需要使用待命資料中心，以便您將伺服器陣列復原到該處。
待命資料中心復原選項
當主要資料中心停止運作，而本機備援系統與備份無法復原時，就需要待命資料中心。 依讓替代的伺服器陣列在別處開始運作所需花之時間與工夫的不同，通常可分為熱待命、暖待命和冷待命。 我們對這些伺服器陣列復原資料中心的定義如下：
冷待命。 可在數小時或數天內提供可用性的次要數據中心。
暖待命。 可在幾分鐘或幾小時內提供可用性的次要數據中心。
熱待命。 可在幾秒或幾分鐘內提供可用性的次要數據中心。
這每種待命資料中心各有其特殊的特性和需求，也有其相關的操作與維護成本。
冷待命災害復原策略：企業定期將支援裸機復原的備份傳送至各地與各區域的異地存放裝置，且簽有合約可在另一區域緊急租用伺服器。
Pros: 通常是維護成本最低的選項，因為不需太多操作。 通常是復原成本較高的選項，因為在發生災害之後，必須正確設定實體伺服器。
缺點：復原速度最慢的選項。
使用 Azure Site Recovery 的暖待命災害復原策略。
Pros: 復原成本通常很低，因為在復原時，虛擬伺服器陣列幾乎不需要進行什麼設定。
Cons: 維護起來可能既昂貴又費時。
熱待命災害復原策略：企業有多個資料中心在運作，但只透過其中一個資料中心來提供內容和服務。
Pros: 復原速度通常相當快。
Cons: 設定與維護成本可能很高。
重要事項
不論您決定套用上述何種災害復原解決方案，遺失一些資料是難免的。
冷待命復原
在冷待命災害復原案例中，您最好使用腳本部署) 並還原備份，在新的位置 (設定新的伺服器數組來復原。 或者，您可以使用備份解決方案來復原伺服器陣列，例如 System Center - Data Protection Manager (DPM) 。 DPM 會在電腦作業系統層級保護您的數據，並可讓您個別還原每部伺服器。 本文不含關於如何在冷待命案例中建立及復原伺服器陣列的詳細指示。 如需詳細資訊，請參閱：
暖待命復原
在暖待命災害復原案例中，您需要在替代的資料中心建立一模一樣的伺服器陣列來建立暖待命環境，並且定期使用主要伺服器陣列的完整與增量備份來加以更新。
虛擬暖待命環境
虛擬化是一種可行且符合成本效益的暖待命復原解決方案選項。 您可以使用 Hyper-V 作為內部解決方案，或使用 Azure 作為代管解決方案，以提供復原所需的基礎結構。 如需詳細資訊，請 參閱在 Azure 中使用 SQL Server Always On 可用性群組部署 SharePoint Server
熱待命復原
在熱待命災害復原案例中，您需要在待命資料中心架設容錯移轉伺服器陣列，以防萬一主要伺服器陣列離線，就能瞬間接手處理實際執行作業。 在另設有容錯移轉伺服器陣列的環境中，具有下列特性：
容錯移轉伺服器陣列上必須另維護一個設定資料庫與 SharePoint 管理中心網站內容資料庫。
所有自訂項目必須同時部署在兩個伺服器陣列上。
提示
兩個伺服器陣列保持一致，並減少出錯的機會，建議您採用指令碼形式的部署，以相同的組態設定與自訂項目來建立主要與容錯移轉伺服器陣列。
兩個伺服器陣列都必須套用作業系統、SQL Server 和 SharePoint Server 軟體更新，讓兩個伺服器陣列維持一致的設定。
您可以使用非同步鏡像、可用性群組複本上的非同步認可，或記錄傳送，將 SharePoint Server 內容資料庫複製到容錯移轉伺服器陣列。
注意事項
SQL Server 鏡像只能用於將資料庫複製到單一鏡像伺服器，但您可以將記錄傳送至多部次要伺服器。
未來的版本將會移除 SQL Server 資料庫鏡像功能。 建議您避免在新的部署中使用此功能。 規劃變更目前使用此功能的應用程式。 請改用 AlwaysOn 可用性群組。
能否透過記錄將服務應用程式傳送至伺服器陣列，各服務應用程式皆有不同。 如需詳細資訊，請參閱本文稍後的＜服務應用程式備援＞。
熱待命伺服器陣列拓撲可以重複運用在多個資料中心，只要您設定 SQL Server 透過記錄傳送至一或多個其他資料中心即可。
重要事項
[!重要事項] 針對災害復原採用容錯移轉作法時，可用的網路頻寬和延遲性是主要的考量因素。 建議您洽詢您的 SAN 廠商，以判斷您是否可以使用 SQL 資料庫的 SAN 複寫或其他支持的機制，在數據中心之間提供熱待命層級的可用性。 請注意，不支持針對 SharePoint 伺服器使用 SAN 複寫。
服務應用程式備援
若要提供跨資料中心的服務應用程式可用性，建議針對可跨伺服器陣列執行的服務，另執行一個可同時讓主要與次要資料中心存取的服務伺服器陣列。
如果服務無法跨伺服器陣列執行，且要提供服務伺服器陣列本身的可用性，為服務應用程式提供跨資料中心的備援，所需的策略各不相同。 採用的策略取決於下列因素：
在未使用的災害復原伺服器陣列中執行服務應用程式，是否有其商業價值。
與服務相關聯的資料庫是否可以透過記錄傳送、受到非同步鏡像，或透過非同步認可受到複寫。
服務應用程式是否可以對唯讀資料庫執行。
在設計一套使用暖待命或熱待命資料中心的災害復原解決方案之前，請檢閱＜SharePoint 資料庫支援的高可用性和災害復原選項＞一文。
復原的系統需求
理想情況是，容錯移轉元件與系統在各方面都符合主要元件與系統：平台、硬體和伺服器數目。 容錯移轉環境至少要能夠處理容錯移轉期間預期會有的流量。 切記，容錯移轉網站可能只需要服務一部分使用者。 系統至少至少要在下列方面相符：
作業系統版本和所有更新
SQL Server 版本和所有更新
SharePoint Server 版本和所有更新
除了先前的需求之外，伺服器數位復原時間也會受到設施和基礎結構元件的可用性影響。 請確定符合下列需求：
電源、冷卻、網路、目錄和 SMTP 受到完整備援
選擇符合您需求的切換機制：DNS 或硬體負載平衡。
另請參閱
概念
SharePoint Server 的高可用性與災害復原概念