當您需要實施某種基於雲的系統恢復技術時,您有兩種路線可以選擇，但費用和風險各不相同。
備份通常都是個很好的策略。您需要有能力在某個地方備份數據和應用程序，以便在某些自然或人為災難的情況下依舊可以保持業務的運行，避免關鍵系統的崩潰。
我們擁有提供備份站點和備份技術的完整解決方案。它們可以是被動式的，這意味著您可以在短時間內恢復站點並重新開始運營。或者也可以是主動式的(成本更高)，這意味著可以在用戶不知情的情況下，用當前的數據和代碼重新發布和接管被禁用的系統。
在雲計算的環境中，災難恢復包含了一組新的選項，它們看起來與您在本地系統中擁有的選項大不一樣。您最終採取的方法應該與應用程序和數據集對業務價值的大小相匹配。我建議您仔細考慮所有這些操作選項的實用性，確保您的花費不會超過災難恢復配置所帶來的價值（ID:ydotpub）。
選項1：區域到區域的災難恢復
您可以在同一個公共雲提供商中設置兩個或更多區域來提供災難恢復能力。所以，如果Virginia區域被移除，那麼該國其他地區就可以接管。
你可以花錢將數據和應用程序的精確副本複製到備份區域，這樣它們就可以無縫地接管(即主動恢復)。或者你可以使用更經濟有效的方法，比如按計劃備份到被動式大容量存儲器，以便快速地在另一個區域重新開始運營(即被動恢復)。
選項2：雲到雲的災難恢復
我遇到的最常見的問題是：如果整個公共雲提供商被摧毀或長期停運時，我們該如何保護自己?
例如，使用一個公共雲來提供對另一個公共雲的備份，可以讓您使用Amazon Web服務來備份Azure，或者反過來，或者做一些其他的配對。
雖然這似乎是災難恢復的終極目標——也是規避風險的終極目標——為了支持災難恢復，多雲計算意味著需要保留兩個不同的技能集，擁有兩個不同的平臺配置，以及其他成本和風險。
然而,進行雲對雲的系統複製(又稱雲間複製)大大增加了出錯的可能性。尤其是在嘗試複製主備份平臺時，這絕對不是您所希望看到的。雖然並非不可能，但云間複製可能比在同一供應商內的雲內複製困難五倍。這就是為什麼除了少數例子之外，支持雲間複製的機構幾乎不存在的原因。
閱讀更多 OTPUB 的文章
