云數據恢復：文檔是成功的關鍵
創建云上的數據恢復計劃，很重要的一點是持續跟蹤基礎架構，DR需求和可能的故障轉移持續時間。
公有云給IT部門提供了***的機會來實現業務的持續性/災難恢復計劃，而無需花費巨資構建獨享的數據中心。有了云數據恢復系統之后，云就可以用作基本數據的存儲庫或者甚至當主要系統出問題時運行應用之處。
當構建DR計劃時，***步是查看用來交付IT服務的應用，并且決定災難發生時需要保護什么。這意味著創建需要運行的應用和服務的清單。很多企業已經轉向虛擬化作為其核心服務器的部署模型;但是，仍然需要考慮物理服務器。完善的云數據恢復計劃應該包括如下：
用來交付基礎架構的物理和虛擬服務器。這些包括活動目錄(AD)服務器，DNS/DNCP服務器和應用。
- 用來交付應用的物理服務器。為什么還在物理服務器上交付服務，這需要有好一點的理由;這可能包括擴展和性能要求，或者使用自定義硬件和操作系統。但是，云恢復服務可能能夠幫助虛擬化其中一些組件。
- 用來交付應用的虛擬服務器。可能有幾十臺或者上百臺虛擬機用來實現應用。每臺都需要確認和記錄、查看存儲、內存和虛擬處理器需求。
***提前確定基礎架構服務器,因為當災難發生時這些系統需要***時間恢復服務。可以預配置在云上運行的AD、DNS和DNCP服務，并且和它們的內部實例同步，讓DR流程更加容易，也能夠更快實現。
要想讓云上的DR能夠成功工作，理解網絡配置至關重要。這意味著需要花時間理解網絡層的應用之間的相互依賴關系，包括安全和防火墻配置。云數據恢復相關的問題有：
- 是否有應用或者服務器互相之間有延遲依賴?
- 是否有East-West防火墻規則來管理站內流量?
- 面向客戶的應用的外部帶寬需求是什么?
確定云數據恢復需求
假定在災難事件發生時，每個應用都需要立即恢復，這并不太實際。相反，應該基于一系列條件來區分應用的優先級，來決定需要多快，以及哪些同步系統和數據需要恢復運營。在決定恢復應用的服務等級時，可以使用一些標準來進行度量：
- 恢復時間目標。它衡量在應序備份并且運行之前可以容忍多長的下線時間;通常以分鐘或者小時計量。比如，零RTO表示完全不能容忍掉線，而一小時的RTO意味著應用必須在DR發生的一小時內完成恢復。
- 恢復點目標。它衡量一旦應用再次運行時可以容忍丟失多少數據。零RPO意味著所有數據都必須恢復到災難發生點，而24小時的RTO意味著恢復后數據或系統可以過時24小時。
- 服務級別目標。SLO衡量整體應用的恢復情況。比如，協議可能是在四小時內恢復90%的應用。越嚴格的SLO要求越多的基礎架構支撐并且可能需要越多的人力才能達到，因此留有一定的靈活度有助于管理DR的費用。
- SLO 允許區分數據和應用的優先級。比如，一個在線信用卡處理系統要求零RPO和非常低的RTO。期望這樣的系統永遠也不會丟失信息是合理的。另一種極端情 況是，負責報告的應用可能能夠容忍24到48小時的數據過期時間，因為其數據是從其他應用里抽取出來的。其他系統大多數處在這兩種極端情況之間。
建立正確的云數據恢復需求包括和應用程序的業務所有者溝通，因為他們了解其應用的重要程度。從經驗上看，業務所有者會認為其所有應用都很重要——直到他們了解恢復所需的費用為止。因此可以告訴他們不同方案的費用評估。
服務級別的***一點是：一些嚴格的需求，比如零PRO，基于云的DR是無法達成的，因為本地和云位置之間會有延時。需要將這些應用排除在基于云的DR之外，并且提供更多定制的DR產品。
DR服務會運行多久?
***需要討論的是，服務會在公有云上運行多久。做這樣的決策依賴于發生的事件類型。并非所有災難都會導致所有在線功能的崩潰。還會存在一些邊緣事件類型，比如：
- 服務器丟失。要么是物理服務器，要么是虛擬服務器主機。虛擬服務器的丟失可能很嚴重，但也可能不嚴重，應用程序需要轉而運行在DR模式。
- 多系統丟失。比如，如果共享存儲陣列出問題的話，可能會失去多個應用。
- 數據中心丟失。在最壞的情況下，整個數據中心都丟失了，或者訪問不了。所有服務都需要運行在DR模式下。
有時候，服務需要移動幾個小時或者幾天。當整個站點都丟失時，需求可能是運行DR服務幾周或者幾個月，直到重建了之前的設備。云恢復服務會為所使用的活動服務計費，因此在選擇DR服務時這是很重要的考核點。
