一旦遭遇劫難，響應必需火速、快速。火警、大水或打單軟件，給企業造成的損失無比奮發，急需以現代的災備手段應對。

傳統的廠商私有+高度定制系統，現代的家產尺度化+開箱即用模塊，所能提供的災備本領截然不同。云上的即開即用方法基于家產尺度化，能提供特另外強大掩護本領。

多中心化，是災備的一種模式，其思路是一其中心數據丟失不行怕，另一中心立即啟用就行。因此，站點位置相距越遠越好。

可多中心的最大問題是本錢。每增加一鏡像中心，按照備份的數據量幾多，IT基本架構支出會多出50%-100%，這還不算特另外能源耗損、設備養護、人員維系等承擔。私有系統+二次開拓的模式，勢必導致這種排場。

磁帶備份，是傳統災備選項之一。數據到磁帶固然利便，但耗時很久（幾小時-幾天）。因此，備份到云，而非磁帶，也適合一些但愿拿來就用的企業。

云更利便災備

因為云，開箱即用型方案能讓災備更溫馨。私有云內的大都應用都運行于虛擬機，因此向公有云遷移不是困難。

實現這個有幾種要領。其一是選擇彈性云，當發生特另外負載時云自動匹配新資源。作者申明，數據托管對RTO很是重要，但本文不會接頭數據托管的任何細節。

另外，終端備份系統會拷貝近期數據和運行實例，以便災備時快速規復。然而利用了民眾云，這種開銷則無需維持了，因為民眾云可在幾分鐘內涵出產系統上籌備好近期數據和實例，立即可用。Docker容器比傳統的hypervisor快許多，是將來的RTO熱點。

災備的重點，不是優化備份東西，而是如何快速規復數據，這個從來都不簡樸。擔保文件存在于正確的處所，擔保規復文件的途徑始終正確，這個很是棘手。災備實施團隊所面對的，永遠都是10年一遇的問題。

細分災備方案

將接頭的是“災備即處事（DRaaS）”。打點層需要明晰，業務持續性的打算實施，是自行處理懲罰照舊寄托于人。無論選擇哪條路，時機本錢都很大，因為導致業務間斷的損失是天文數字。

選擇哪條路，需要很好的TCO闡明。單個產物也許無法適配，混搭方案也許行之有效。

(一)如下環境，可選擇云備份：

1.業務不急著取用數據。當地的冷存儲方案，及任何對RTO不敏感的需求，都適合此用例。

2.在民眾云中重建實例/鏡像不巨大。

3.公司有專門的DR人才，莫斯科服務器 新加坡vps，而且至少每半年愿意舉辦災備測試。

（二）如下環境，“災備即處事”是更好的選擇：

1.打點層不懂技能。

2.RTO要求很短。

3.應用基本架構很認真。

凡是DRaaS本錢遠遠高出單獨的備份。但DRaaS供給商按需利用的本領，也覺得著其本錢能大大低落。雖然，具體的TCO闡明是決定的須要前提。

最后提提備份/災備的東西。很多云東西利便了備份，個中最優秀的東西甚至省卻了大量的二次開拓事情，同時答允從節點到數據中心級的數據規復。這些東西都具有精采的接口和打點要領，在規復進程始終保持各規復工具的一致性。