有不少人對傳統離線的災難恢復和云計算中的災難恢復這兩個概念還存在著混淆。弄清楚其中的差異與恢復需求是維持一個固定災難恢復策略的第一步。

　　無論是否是在云計算中實施災難恢復，一個成功災難恢復計劃所包含的要素都是相同的：

　　1.用于災難的計劃

　　2.記錄你的計劃

　　3.測試你的備份文件

　　4.修正任何存在的問題

　　5.再次測試，以確保你已解決了所有的問題

　　6.經常性地重復上述步驟

　　最后一步的“重復”是讓災難免于發生的關鍵所在。

　　災難恢復技術已從基于磁帶的恢復技術和租用數據中心空間對重要服務進行恢復發展至即時地從發生故障的站點切換到虛擬的失效備援站點。在云計算災難恢復供應商如何管理離線組件，或他們如何對一個IT環境實現云計算化方面是存在著差異的。有些人可能會說，他們相信災難恢復可通過云計算實現，而有些人則不這么認為。

　　大多數廠商將設備插入到客戶的IT基礎設施，以獲取信息并將其存儲在本地，然后復制到云中。在絕大多數情況下，事實上數據并不會存在于云中；實際上數據被轉移至供應商的數據中心中。這一方法類似于傳統的備份解決方案。這一方法的本地化和高速可允許你從發生非災難性數據丟失事件的設備中恢復數據。在將被保護站點離線的實際災難事件中，離線數據通過互聯網重新上線。

　　一旦你了解到災難事件中數據的位置，確定滿足公司需求的恢復點對象（RPO）和恢復時間對象（RTO）成為了IT團隊和業務經理的首要任務。雖然可能有許多公司都要求“永遠在線、永不掉線”的運行，但是實際的預算和災難發生概率都在時刻提醒他們，他們的這一需求是完全不必要的。最重要的是要制定出切實可行的災難恢復目標。

　　對于那些依賴于技術創造價值的公司來說，一個零RPO/零RTO的準則同樣有效；為這個災難恢復計劃支付費用是組成這一業務成本的一部分。而對于其他的公司，計算機網絡保險和高RPO/RTO就足夠了。業務規模越大，其組合復雜程度越高，同樣RPO和RTO需求的復雜程度也越高（從0/0到8小時/24小時設置，甚至于更為復雜24/24的需求。）

　　云計算選項中的災難恢復

　　虛擬化是基于云計算災難恢復技術的基礎。在這個過程之后，就成為了一個真正的云計算服務。諸如IBM公司、Iron Mountain公司、CommVault公司、Simply Continuous公司和AppAssure公司等主要供應商提供了基于云計算的商業級災難恢復產品，該產品旨在整合業務標準和流程、報告活動并可使IT團隊和業務單位了解產品狀態。

　　已創建用于恢復IT環境的虛擬機（VM）與你使用物理機器在專用設施中使用的虛擬機并無不同。其中唯一的差異在于這些虛擬機托管于一個第三方設施中并基本上從云中運行。當被保護設施的指示燈熄滅，同時調用災難協議，那些虛擬機替代了物理機器和虛擬機器——接管生產機器。

　　該方法是SLA友好的。能夠以可控的方式使用存儲災難恢復數據和應用程序的虛擬機。這一點可確保你管理系統能力和成本。如果一個業務單位基于Web訂單處理系統的RTO為四小時，而一個常用但不重要的客戶訂單歷史記錄歸檔系統RTO為48小時，那么服務水平協議將要求災難恢復產品立即恢復基于Web的訂單處理系統，并在其后恢復歷史記錄歸檔系統。這一機制保留了恢復服務的兩個目的：它降低了與任何時間相關的成本，并賦予忙碌的IT人員時間以確保首先滿足更為關鍵的SLA。

　　這一分階段恢復計劃還允許用于消除災難的時間。當然，還必須考慮到徹底破壞情況下的恢復計劃；但是，在大多數情況下，災難是指一次簡單的失效。一旦發出失效命令并選中相關設施，你可能不需要為并不重要的SLA運行災難恢復協議。