當您需要實施某種基于云的系統恢復技術時,您有兩種路線可以選擇，但費用和風險各不相同。

備份通常都是個很好的策略。您需要有能力在某個地方備份數據和應用程序，以便在某些自然或人為災難的情況下依舊可以保持業務的運行，避免關鍵系統的崩潰。

我們擁有提供備份站點和備份技術的完整解決方案。它們可以是被動式的，這意味著您可以在短時間內恢復站點并重新開始運營。或者也可以是主動式的(成本更高)，這意味著可以在用戶不知情的情況下，用當前的數據和代碼重新發布和接管被禁用的系統。

在云計算的環境中，災難恢復包含了一組新的選項，它們看起來與您在本地系統中擁有的選項大不一樣。您最終采取的方法應該與應用程序和數據集對業務價值的大小相匹配。我建議您仔細考慮所有這些操作選項的實用性，確保您的花費不會超過災難恢復配置所帶來的價值。

選項1：區域到區域的災難恢復

您可以在同一個公共云提供商中設置兩個或更多區域來提供災難恢復能力。所以，如果Virginia區域被移除，那么該國其他地區就可以接管。

你可以花錢將數據和應用程序的精確副本復制到備份區域，這樣它們就可以無縫地接管(即主動恢復)。或者你可以使用更經濟有效的方法，比如按計劃備份到被動式大容量存儲器，以便快速地在另一個區域重新開始運營(即被動恢復)。

選項2：云到云的災難恢復

我遇到的最常見的問題是：如果整個公共云提供商被摧毀或長期停運時，我們該如何保護自己?

例如，使用一個公共云來提供對另一個公共云的備份，可以讓您使用Amazon Web服務來備份Azure，或者反過來，或者做一些其他的配對。

雖然這似乎是災難恢復的終極目標——也是規避風險的終極目標——為了支持災難恢復，多云計算意味著需要保留兩個不同的技能集，擁有兩個不同的平臺配置，以及其他成本和風險。

然而,進行云對云的系統復制(又稱云間復制)大大增加了出錯的可能性。尤其是在嘗試復制主備份平臺時，這絕對不是您所希望看到的。雖然并非不可能，但云間復制可能比在同一供應商內的云內復制困難五倍。這就是為什么除了少數例子之外，支持云間復制的機構幾乎不存在的原因。