當前，數據安全受到多方面的威脅。有來自系統軟硬件的非人為故障，有運維工程師的誤操作，甚至是黑客或內部人員的惡意刪除。2017年1月31日，全球最大的代碼托管服務平臺Gitlab由于工程師的誤操作，刪除了5000個項目和700個用戶賬號的數據，雖然多方補救，但部分數據最終沒能恢復。近幾年黑客入侵用戶系統后加密磁盤，以此來勒索的事件也層出不窮。更有來自黑客或內部人員的惡意刪除，導致業務的極大損失。

　　如何徹底杜絕此類風險，確保數據安全，需要全方位的技術保障措施：備份、反入侵、分權限管理、快速回檔等技術手段都不可或缺，而且必須覆蓋每一類存儲產品。

　　UCloud作為業界領先的云服務商，提供了全面的各類存儲產品，開發了完整和成熟的數據安全機制。并且在為數萬家用戶提供可靠線上服務的過程中，積累了豐富的經驗。下文提到的數個案例，其實就發生在UCloud平臺上。通過我們的產品和專業及時的服務，這些用戶最終得以恢復數據，避免由此造成的損失。

　　一般地說，用戶搭建數據庫有如下三種方式：使用公有云提供的DB PaaS托管服務，如UCloud UDB，由云服務商來負責DB的搭建及運維;用戶也可以使用公有云的云主機和云盤來自行搭建數據庫;或者在私有云環境下搭建。在這三種情況下，UCloud都提供了專業的數據安全機制，來切實有效的保證用戶的數據安全。

　　接下來將介紹UCloud針對數據庫數據安全的七種“武器”。具體而言，本文主要回答如下三個問題：

　　1. 數據庫的備份容災機制如何完善?

　　2. 數據被破壞丟失后如何快速恢復?

　　3. 數據庫運維人員的權限如何有效控制?

　　UDB PaaS托管服務

　　如果需要得到最專業的數據庫安全服務，用戶的首選就是云服務商提供的DB PaaS服務。譬如說，UDB是UCloud提供的云數據庫服務，支持各種主流的數據庫產品。自2013年上線以來，運營了數以萬計的UDB實例。

　　UDB遠遠不只是幫用戶搭建DB那么簡單，事實上這部分功能只是UDB價值的冰山一角。UDB提供了完備的數據庫搭建、運維、性能調優、資源擴縮容等服務。其高可用、高性能、便捷易用等特性幫助用戶大量減輕了運維負擔。同時，數據庫團隊還自研了分布式架構、讀寫分離、存儲計算分離等特性，進一步提高云數據庫的性能和可用性。在數據的備份恢復機制上，UDB提供自動備份、秒級恢復、監控告警、問題診斷等服務。

　　武器一：UDB備份機制

　　面對不可預測的誤操作或者人為惡意操作，數據庫自身的備份機制就顯得尤為重要。UDB的備份機制具體如下：

　　(1)UDB的備份模式

　　自動備份每天自動進行一次備份(默認備份時間為00:00—06:00的某一整點)，備份可以保存7天。備份模式包括物理備份和邏輯備份兩種。

　　用戶可以對某些關鍵時間點的重要數據進行手動備份，允許保留個數為3個。

　　(2)UDB備份文件存儲

　　備份文件存儲在UCloud獨立的備份資源池中，安全性有保障。

　　備份文件的副本始終保持多份異地冗余。

　　(3)備份文件轉存

　　針對用戶個性化的備份文件存儲需求，UDB支持備份文件下載：

　　Web控制臺或API支持下載備份文件(包括自動備份和手動備份)。

　　Web控制臺或API支持下載二進制日志文件(MySQL的binlog) 用戶在下載備份文件后，可轉存到自有的存儲系統或者UCloud平臺上的存儲類產品(UDisk、UFS、UFile等)，理論上采用公有云存儲產品更為安全可靠。

　　(4)備份成功率保障機制

　　UDB的自動備份具備有效的告警機制，如果備份失敗，則會自動觸發告警。

　　UDB后臺會定期進行備份成功率的巡檢，通過SPT反饋備份情況給到用戶。

　　武器二：數據恢復方案

　　針對誤操作或者人為惡意造成的數據庫刪除，UDB提供了一系列數據恢復方案。

　　對UDB實例中的庫做刪除，比如drop/delete操作，可以從源實例通過回檔功能恢復到操作的前一刻，回檔到一個全新的實例。

　　UDB實例被刪除后，它原先的備份將持續自動保留7天，7天內仍然可從備份恢復為一個全新實例。

　　出現最極端的情況，實例被刪、備份文件全部被刪，那該怎么辦呢?UDB后端在一定有效期內仍然保留有操作當天的最新備份，應對該極端情況。由于這份備份是系統內部維護，用戶并不能直接訪問。所以即便發生運維人員惡意刪除，此份備份依然存在，仍然可以使用該備份來數據恢復。

　　武器三：從本地備份到跨云備份

　　為了確保數據的絕對安全，必須做到數據的多份備份，可以從本地磁盤的多份備份到跨區域備份，甚至實現跨云平臺的多云備份。

　　數據庫數據可靠性受底層有效的RAID保護，實例級的冗余則包括主實例采用高可用架構，后端主備雙節點，保證數據雙份冗余。控制臺一鍵創建從實例，主實例可以一主帶N從，包括可用區級(主從在同可用區)和地域級(主從跨可用區)，保證實例級冗余。

　　UCloud還提供數據傳輸產品UDTS，在數據庫可靠性更高要求的場景，主實例可以通過UDTS搭建異地或者兩地三中心的UDB集群架構，進一步保障數據安全。此外，UDTS也適用于多云部署的場景，其支持多種數據庫類型、雙向遷移的能力，可以幫助使用者將數據平滑地做跨云的遷移和備份。某電商便是借此實現了UCloud和T云之間的數據同步。

　　UDB數據恢復案例

　　1

　　場景一：數據庫誤變更

　　游戲行業業務變更快、變更多，是比較容易造成數據庫誤操作或者不當變更的情況，此時如何快速恢復到變更前狀態就成為了棘手的問題。某游戲用戶在版本發布時造成數據庫的schema變更字段出錯，發現出錯時，已經對游戲服造成了巨大影響。此時，管理人員對影響的UDB實例做了一個回檔操作，恢復至變更前一刻，精確到秒級，挽回了損失。再對源實例進行必要數據的導出，補償到回檔的新實例，避免數據丟失。

　　場景二：數據庫誤刪除

　　在運維權限管理混亂時，安全性就存在巨大的隱患，任何人都有可能對核心資源進行不正當操作。某互聯網App用戶的運維人員由于看錯信息，造成核心UDB實例誤刪除。因UDB實例會每天自動備份，此時管理人員在控制臺找到UDB實例當天的最新備份，做了恢復操作，恢復為一個全新UDB實例，減少了損失。

　　場景三：數據庫誤回收

　　在生產環境里，最為擔心的是資源的回收未及時發現，例如(1)運維人員在資源整合時，刪除了某個數據庫實例;(2)過期資源未及時續費被自動回收，事后過了很長時間才反應過來，但為時已晚。針對該場景，UDB實例后端在一定有效期內，仍然保留一份當天的最新備份，通過數據全量恢復的模式，幫助不少用戶找回數據。

　　使用云主機自建DB

　　如果用戶出于各種原因考慮，不愿意使用公有云的DB PaaS托管服務，而是希望使用公有云IaaS產品來自行搭建DB。UCloud同樣提供了專業的數據安全產品，那就是數據方舟。方舟是當前業界獨一無二的數據備份產品。通過在虛擬化層的I/O路徑改造，方舟可以把用戶的原始塊設備存儲放在后端去存儲，并且能實現按秒的回滾。

　　武器四：數據方舟持續保護

　　對于數據備份產品，有兩個重要的能力評估指標——恢復點目標(RPO)和恢復時間目標(RTO)，目前數據方舟的RPO已經達到秒級別，默認支持12小時內恢復任意一秒，24小時內任意整點恢復，3天內的任意零點恢復，用戶甚至可以自由定制備份鏈秒級、小時級、天級的保護范圍，并且是恢復到一塊新的磁盤上;而數據方舟的RTO則能夠達到最短5分鐘內恢復，即使是TB級別的數據量，也可以做到半小時內恢復。

　　數據方舟是如何在技術上做到對用戶數據的持續保護呢?數據方舟后端使用了分層混合存儲設計，用戶的實時I/O會通過旁路以oplog的方式記錄到方舟的接入節點(FRONT)上，由于方舟接入節點采用了高速磁盤設備，能夠扛住用戶大量的I/O寫操作。

　　流式計算節點SHUFFLE會拉取接入節點的oplog進行批量處理，主要是進行數據分片(sharding)，并將數據分片推送到最終存儲層(ARKER)進行存儲。隨著時間的流逝，ARKER也會不斷對數據進行合并，最終形成base/天級/小時/秒 四個級別的數據備份鏈。

　　用戶恢復時，會調動后端集群所有節點的能力進行并行計算，加快恢復速度。值得一提的是，用戶恢復時當前的磁盤數據是保留的，數據會回滾到一塊新的磁盤上，這樣做的目的是如果用戶回滾后后悔，也能夠回到恢復前的數據狀態。

　　數據方舟恢復數據案例

　　案例一：勒索病毒

　　2017年5月“永恒之藍”病毒爆發，全球大量Windows主機受到感染，企業重要文件被加密，只有支付高額贖金才能解密恢復文件。萬戶印刷公司的一臺云服務器也遭受到了病毒攻擊，用戶的印刷文件被加密。

　　案例二：誤操作導致文件系統異常

　　2017年12月，某AI公司遭遇到了重大危機，其運維人員在對存放重要數據的云硬盤進行擴容時，違規操作，導致硬盤出現了文件系統故障，數據無法訪問。問題磁盤有著多個分區，該公司缺乏對多分區磁盤進行文件系統修復的經驗，不敢貿然修復，擔憂會因此導致數據進一步損壞。

　　案例三：游戲回檔

　　2019年3月，某知名端游公司出現了嚴重的運營事故，一個道具的復制漏洞導致了游戲的平衡性失調，嚴重影響玩家體驗，因此需要快速完成回檔，保證對玩家的影響降低到最小。

　　這些案例中，用戶最終都通過UCloud旗下的數據方舟產品進行恢復，迅速找回了所需要的數據。

　　私有云DB的數據安全備份

　　如果用戶的DB搭建在私有云環境下，沒關系， UCloud的對象存儲產品UFile是一個海量的通用存儲產品。通過和第三方產品結合，即便是私有云的DB同樣可以利用公有云海量及可靠的存儲服務，實現數據的高可靠性。

　　武器五：UFile對象存儲幫助數據庫備份

　　塊存儲上數據的保護不僅可以通過數據方舟解決，用戶還可以使用基于 UFile 做數據持久化的 JuiceFS 存儲數據庫備份，JuiceFS 是為云端設計的 POSIX 共享文件系統，具有如下特點：

　　云端：采用云服務中的對象存儲作為后端，綜合性價比極高。

　　POSIX：兼容標準 POSIX 接口，可以像本地文件系統一樣使用。

　　共享：上千臺機器同時掛載，高性能并發讀寫，共享數據。

　　UFile是UCloud自研的對象存儲系統，兼容s3協議，具備高可用、高可靠和低成本的數據存儲服務，提供多副本、跨地域等數據冗余機制，支持三地及以上的跨地域災備功能。使用UFile用戶可以實現高可靠、低成本的云上和跨云的數據備份，包括數據庫備份、日志、大數據文件等。

　　基于UFile+JuiceFS搭建MySQL備份

　　UCloud用戶下廚房是國內最大的專注于家庭美食領域的社區，目前擁有超過四千萬注冊用戶，海量的業務也讓下廚房對數據庫的冗余和備份格外的重視，并且總結出一套非常高效和可靠數據庫災備經驗。

　　除建立了跨可用區的主從節點外，下廚房會進行定時的整庫備份和實時的binlog備份。下廚房的數據庫備份借助了UFile、JuiceFS和Percona Xtrbackup。使用JuiceFS用戶可以無需修改代碼就可以替換之前的本地備份。并且可利用JuiceFS后端的對象存儲來解決無限存儲空間、跨區域復制以及低成本等問題。下廚房的策略是保留 7 天內的 Percona XtraBackup 整庫備份、3 年內的 binlog 以及 1 年內的周級 mysqldump。

　　除此之外下廚房還想到了一個非常具備腦洞的備份驗證方案。有了備份還無法做到高枕無憂，因為有時備份文件會出錯，等到需要恢復時才發現備份出錯就已經晚了。但是備份的驗證是個非常耗時的工作，需要拷貝備份到本地進行恢復。下廚房利用JuiceFS的快照功能，克隆一份備份文件，在不影響原備份文件的情況下快速做驗證，省下大量拷貝的時間。

　　詳細實踐可參考鏈接：

　　https://juicefs.com/blog/cn/posts/xiachufang-mysql-backup-practice-on-juicefs/

　　賬號和權限控制

　　在具備一定的備份和恢復機制下，數據庫運維管理人員的權限控制問題仍然不可忽視，例如將數據庫操作權限和備份權限進行分離、權限審批和操作執行分離、增加數據庫命令隔離層等。

　　武器六：子賬號

　　在權限管理控制方面，UCloud支持用戶為自己的賬戶開設子賬號，并定義為相應的角色。角色是一組產品權限的集合。若某成員的角色被修改，則其相應的權限也隨之變更。子賬號的存在有助于貫徹“最小權限管理”原則，只賦予工作職責所需的權限。大部分成員或許只需云資源的只讀權限，少量操作者可擁有修改的權限，而刪除權限必須通過管理員的審核。

　　多級賬號權限控制，可以有效的控制多級人員的操作權限，最大程度的降低來自內部人員惡意操作的可能。

　　武器七：安全鎖

　　安全鎖是云資源高危操作的二次驗證服務。開啟該服務后，每次進行刪除資源等危險操作時，需要通過手機短信校驗身份才可。

　　受安全鎖保護的高危操作例如有：

　　寫在最后

　　黑格爾曾說：“人類從歷史中學到的唯一教訓，就是人類無法從歷史中學到任何教訓。”云服務發展到今天，已經實現了多種完備的數據安全方案。如本文提到的UCloud七種武器，無論用戶使用哪一種方式部署數據庫，必有一款適合你。企業在今后發生數據庫機器故障、誤操作、惡意刪除等情形時，能否充分利用云服務商提供的數據備份、恢復機制以及賬號權限控制等能力，是解決數據丟失問題的關鍵。