雲資料恢複：文檔是成功的關鍵

建立雲上的資料恢複計劃，很重要的一點是持續跟蹤基礎架構，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服務時這是很重要的考核點。

本文轉自d1net（轉載）