現(xiàn)在很多企業(yè)的數(shù)據都選擇上云。然而，即便是將業(yè)務數(shù)據存放在國內外知名的云平臺，也免不了掉鏈子。
2018年8月，騰訊云“數(shù)據丟失事件”在業(yè)界引起極大的關注，云主機，因騰訊云發(fā)生故障和人為操作失誤，直接導致創(chuàng)業(yè)公司“前沿數(shù)控”數(shù)據全部丟失，公司面臨業(yè)務停擺的威脅。
在騰訊云的復盤中發(fā)現(xiàn)，該故障緣起于因磁盤靜默錯誤導致的單副本數(shù)據錯誤，再加上數(shù)據遷移過程中的兩次不規(guī)范的操作，導致云盤的三副本安全機制失效，并最終導致客戶數(shù)據完整性受損。
事實上，騰訊云并不是唯一出現(xiàn)過故障的云平臺。2018年6月，阿里云因bug禁用內部IP導致鏈路不通，造成1000+公司業(yè)務癱瘓，損失過億；2017年4月，全球知名云平臺AWS發(fā)生大規(guī)模存儲故障，導致大量全球知名業(yè)務中斷。
以上是云平臺自身原因引起的災難性故障，其實還有外部因素導致的問題：
2017年5月，全球爆發(fā)的Wannacry勒索病毒，VPS，給網絡帶來了未有的挑戰(zhàn)，云平臺也不能完全幸免；
2018年1月，Intel芯片設計缺陷，給整個IT架構帶來災難性影響，云平臺性能和安全受到極大的挑戰(zhàn)。
除了公有云暴露出的這些嚴重故障外，幾乎每天都能聽到發(fā)生在企業(yè)內部的私有云，因為軟件缺陷、人員、電力異常等各種原因導致的業(yè)務中斷、數(shù)據丟失，企業(yè)正常的生產受到極大的影響，損失無法估量。
這些內部、外部因素疊加在一起，實際上帶來了幾乎無法規(guī)避的現(xiàn)實：
云也會宕機，也會丟失數(shù)據。
很多企業(yè)對于云服務存在一定誤解，認為將數(shù)據放到云平臺上就萬無一失了。從云計算的本質來看，它為企業(yè)提供的是一個低成本的計算資源共享池，它能幫助企業(yè)提升效率，減少成本，但這不代表它是一個不會出問題的服務。
目前，云服務商在提供服務時都會明確知會客戶，因為當前人類技術水平的限制，服務商能夠提供的服務的可用性、可靠性都做不到100%，大致能做到幾個9(如99.9999%)。
因此，為了在此基礎上繼續(xù)提高數(shù)據的安全性，一般的解決方案是，同時使用該服務商不同區(qū)域的服務器，這樣出問題的概率就會更低。此外，對于重要數(shù)據，不管是個人用戶還是企業(yè)用戶，都需要定期做好備份。如果使用云服務，快照、災備、離線備份等多種方式都可實現(xiàn)數(shù)據備份。
做好災備，提高數(shù)據安全性
數(shù)據備份的任務與意義就在于，當事故發(fā)生后，通過備份的數(shù)據完整、快速、簡捷、可靠地恢復原有系統(tǒng)，而備份數(shù)據可用性的高低是企業(yè)災難恢復的根本。
目前來看，主要的數(shù)據備份方式如下：
定期磁帶備份：
包括遠程磁帶庫、光盤庫備份和遠程關鍵數(shù)據+磁帶備份。
數(shù)據庫備份：
就是在與主數(shù)據庫所在生產機相分離的備份機上建立主數(shù)據庫的一個拷貝。
網絡數(shù)據：
這種方式是對生產系統(tǒng)的數(shù)據庫數(shù)據和所需跟蹤的重要目標文件的更新進行監(jiān)控與跟蹤，并將更新日志實時通過網絡傳送到備份系統(tǒng)，備份系統(tǒng)則根據日志對磁盤進行更新。
遠程鏡像：
通過高速光纖通道線路和磁盤控制技術將鏡像磁盤延伸到遠離生產機的地方，鏡像磁盤數(shù)據與主磁盤數(shù)據完全一致，更新方式為同步或異步。
這些措施能夠在系統(tǒng)發(fā)生故障后進行系統(tǒng)恢復，但是這些措施一般只能處理計算機單點故障，對區(qū)域性、毀滅性災難比如：
地震、火災等則束手無策，也不具備災難恢復能力。
所以，我們就需要建立異地容災中心，做數(shù)據的遠程備份，在災難發(fā)生之后要確保原有的數(shù)據不會丟失或者遭到破壞。建立的異地容災中心可以簡單地把它理解成一個遠程的數(shù)據備份中心。
數(shù)據容災的恢復時間比較長，但是相比其他容災級別來講它的費用比較低，而且構建實施也相對簡單。主要的實施方法如下：
實時復制：
當主中心的數(shù)據庫內容被修改時，備份中心的數(shù)據庫內容實時地被修改，此種復制方式對網絡可靠性要求高。
定時復制：
當主中心的數(shù)據庫內容被修改時，備份中心的數(shù)據庫內容會按照時間間隔，周期性地按照主中心的更新情況進行刷新，時間間隔可長(幾天或幾個月)可短(幾分鐘或幾秒鐘)。
存儲轉發(fā)復制：
當主中心的數(shù)據庫內容被修改時，主中心的數(shù)據庫服務器會先將修改操作Log存儲于本地，待時機成熟再轉發(fā)給備份中心。
