阿裡十年DBA經驗産品經理：真的不要再有一起删庫跑路事件了

最近網上又出一起删庫跑路事件，本不想過多寫此類事件文字，但從業13年，十年DBA工作經驗，職業素養還是驅使自己寫點内容，以期能夠幫助廣大企業客戶。

本文主要以資料庫産品從業者角度，介紹幫助企業減少意外或有意對資料庫删資料的破壞行為，關于資料安全的其他内容如加密等不做過多描述。為了闡述友善，會引入一些RDS功能介紹。

###子賬号體系

針對資料被删除的場景，從“大”到“小”都需要防護，包含執行個體、資料庫、表、記錄行。尤其是最大的資料機關，資料庫執行個體，是需要特别保護的，否則删除一個執行個體破壞性實在太大了，而且就目前所知這個破壞性是比較徹底的，假設沒有做任何額外備份保護，删除執行個體後再恢複是完全沒有這種可能。

阿裡雲針對這種執行個體級保護，主要是通過主子賬号體系來實作的，主賬号建立資料庫執行個體，然後通過子賬号授權DBA等管理人員維護資料庫執行個體。針對按量執行個體，在删除執行個體的時候會收到短信驗證碼，保障每次删除都是正确的；針對包年包月執行個體，在執行個體到期前就會有短信通知續費，到期後會鎖定7天，期間可随時恢複，7天後執行個體釋放但會将最新全備檔案放入資源回收筒保留8天，是以在執行個體到期後客戶依舊有15天時間來恢複資料。此外由于本次疫情，阿裡雲針對所有RDS包月執行個體到期時間都做了延期鎖定動作，保障在疫情期間因為延遲上班導緻的延期交費執行個體不被鎖定。

前面提到我們删除執行個體的破壞性是比較徹底的，因為目前大部分廠商的資料庫的備份都是跟着資料庫執行個體走的，即執行個體删除後備份檔案也随之清空，此時就沒有任何恢複手段了。在2019年底，我們針對此場景，特别設計了删除執行個體後保留備份檔案的功能，已經上線，這樣在執行個體删除後，依舊預設保留備份檔案，以便随時恢複，并且暫時是0元優惠的，大家可免費使用。

DBA賬号和研發賬号分開

資料庫執行個體能夠保證安全後，并不能夠保證資料庫就是安全的，比方說最近這個案例，可以通過删除執行個體中的資料實作破壞。以MySQL為例，資料庫中的資料以表和資料庫形式組織起來，以記錄行承載具體的資料，對資料庫和表的保護尤其重要。

對資料保護的原則還是權限分離，最基本的權限分離還是要做到的，化繁為簡在RDS MySQL中我們設計了兩種權限類型使用者，分别是“讀寫”權限使用者和“隻DML”權限使用者，讀寫權限使用者有DDL的權限，是以我建議給業務系統使用的資料庫使用者選擇“隻DML”權限，而不應該給予“讀寫”權限，以此避免通過編寫一個惡意程式去删除資料庫中的表或者整個資料庫了。

據我所知，有不少企業業務系統中，會給應用系統以DDL權限，即在業務運作過程中系統會去自動建立表和删除表，比方說某些ERP系統是此類設計方案，這就無法避免要授予“讀寫”權限使用者給應用系統。另外在MySQL的權限體系中，有一個drop權限，其特性非常有意思，擁有這個權限就具備的删除表和删除資料庫的能力。是以這個場景，在一定程度上就加重了資料安全隐患。為了解決這種場景，我們專門在AliSQL核心層設計了一個資源回收筒，這樣縱然業務系統執行了drop table等操作，DBA依舊可用在核心資源回收筒中快速的把資料找回。

如果要對表中資料行進行保護，就會相對比較複雜，除了通過binlog來反向更新找回資料外，我建議客戶可以開通SQL洞察功能，SQL 洞察除了用于審計，也可以用于找回資料。當然于此，DMS企業版也是我強烈推薦的一款産品，這款産品是過去阿裡DBA團隊内部研發流程管理的結晶，釋出與復原、表級權限的精細粒度控制、單行資料的masking等，都是專門的資料保護特性。

備份和恢複體系

資料保護的最後法寶永遠是備份，如果沒有備份，能夠保護資料的程度是很有限的，記得前兩年有個公司自建資料庫，認為雲盤有很高的資料可靠性保障就可以安全無憂，但是凡是代碼就有bug，最後的悲劇大家也比較清楚。無論是實體損壞、或人為損害，備份就是最後的救命稻草。

在阿裡雲RDS中，會強制要求備份檔案至少保留7天，每周至少做兩次全量備份，與AWS允許不備份的設計不同，我們這樣做真的是為了保護客戶，與國外環境不同，中國的DBA從業人員本來就少，有意識備份是少之又少，是以在這裡我們做的和AWS不一樣。同時為了降低成本，我們開發高壓縮比的備份技術，一般壓縮7到10倍，并且贈送50%執行個體存儲空間的免費備份空間。

另外有一個特别的建議，希望大家都能夠打開RDS的日志備份，這樣在恢複的時候可以實作恢複到時間點，可以最大程度保護企業資料。若關閉日志備份，那麼極端情況隻能恢複到上次全量備份時間點，比方說一周兩次則有可能是三天前，是以我們建議僅對如開發測試環境資料庫關閉日志備份，所有的生産資料庫都應該打開日志備份。

災難發生時，資料庫恢複技術就顯得尤其重要，當然前提得有備份。我們過去隻提供了克隆執行個體功能和覆寫性恢複功能，在災難發生時，支援使用者把資料恢複到一個新執行個體，或者恢複到老執行個體（覆寫恢複）。

在18年的時候，我們取消覆寫恢複的功能，因為這個功能其實是非常危險的，如果覆寫恢複過程出現異常，那麼資料錯亂将會更麻煩，這在當時是個痛苦的決定。資料庫恢複（克隆執行個體）是挽救資料的法寶，但是恢複效率也是非常重要的，否則意外發生時，也許需要幾天才能恢複（取決于資料庫大小），是以在19年我們全面上線了庫表級恢複能力，支援隻恢複一個單表，這樣如果某種表資料丢失或者錯亂，可以快速的恢複，效率上是數量級的提升。另外針對一些更特殊場景，我們上線了RDS跨地域備份功能，其意義就不多說了。

關于備份恢複提最後一點，長期的定期的恢複演練是非常有必要的，否則你無法知道備份是否有效，相關版本是否比對等，當然RDS已經在系統上實作這個機制，客戶可以放心使用。

給自建和同行朋友的建議

上面談到的幾點都以RDS舉例來說明的，對于在ECS自建或者IDC自建的朋友，我們也是希望能夠和我們一樣，加強對資料庫的保護，一些切實可行的動作包括：

· 重新Review下資料庫權限體系，最基本的權限分離還是要做到的，千萬不要有grant all on . 的使用者給到應用系統，因為凡是系統就會有bug，有些時候結果是超出想象的。

· 定期備份機制一定要做起來，雖然此舉涉及成本投入，但這是我們DBA行業的職業素養，不可得過且過。

· 定期演練也要做起來，意外發生時，你就是公司所有人的希望，甚至是你一年中唯一的閃光點，千萬不要手抖。

關于我們的同行，在這裡我也呼籲盡快完善産品功能，庫表級恢複、跨地域備份、備份獨立存儲（執行個體删除後依舊保留）、核心資源回收筒、秒級恢複，這些功能都是我們走訪調查大量客戶後的研究總結，全力完善起來對所有客戶都是有意義的。

給DBA和管理者的建議

雖然說RDS做了很多功能來保護客戶資料，但是個人認為一切的核心還是在于人。對于這次事件，我認為是個遺憾也是悲劇，也許有種種原因，但是這樣的操作是不理性的，不僅僅是對一家公司的破壞，也許甚者對背後多個家庭或者行業都有破壞性，另外也會加深外界對整個行業從業者的誤解。