2月2日，當我們依舊在享受春節假期的時候，卻不知大洋彼岸的Gitlab經歷了一次慘痛的運維事故。
一位操作員為解決一個惡意攻擊的問題，在工作到深夜并極度疲勞的狀態下，誤刪除了主數據庫的數據!在這位操作員意識到問題并立刻終止了移除文件夾操作，但是已經太遲了——300GB的文件只剩下4.5GB。
Gitlab隨后試圖通過可用的備份文件用于恢復生產環境時，他們發現，采用的五種備份方式居然鬼使神差地在這一刻都失效了!最終導致Gitlab.com 官方網站宕機長達十個小時。
雖然Gitlab最終挽回了部分損失，但仍然丟失了6個小時的數據。
非常值得尊敬的是，Gitlab官方在youtube上直播了的整個恢復過程，為所有的IT運維人員敲響警鐘：自己的運維情況如何?如果這件事情發生在自己身上，會不會做得更好?
· GitLab使用的五種備份機制分別是：
· LVM快照(24小時做一次);
· 日常備份(24小時做一次);
· S3備份;
· Azure備份(只對 NFS 啟用，對數據庫無效);
· 自動同步;
但是當這次事故發生時，所有備份全部無效!作為一個在數據保護領域工作多年的老司機，這件事引起了我強烈的興趣。究竟這些備份是如何失效的?對其他數據庫管理者，通過這件事情，我們能學到什么?
首先，Gitlab將LVM的復制周期設置為24小時。作為一個防止誤操作的屏障，這個周期明顯太長了。但是好在這個備份副本具有比較高的可靠性，在實在沒辦法的時候還可以指望得上。實際上Gitlab最后就是利用了LVM的復本對數據實現了恢復。這本應是最終的一道屏障，事實證明，卻是可用的唯一屏障。
日常備份也是24小時進行一次，但最后卻發現日常備份實際上并沒有生效。“高效運維”公眾號的筆者認為，這里的日常備份指的是Gitlab官方提供的命令行腳本，每天打包一次。很多數據庫高手貌似都喜歡使用命令行腳本，但是，一個備份作業是否完成是需要反饋的。命令行指令沒有完成的反饋，很容易就淹沒在各種交互信息里了，誰也不知道這個日常備份已經有多久沒有執行了。另外，如果如推測所言，這個備份只能保護數據庫本身，對整個計算系統是沒有保護的。
原文還提到了基于數據庫的pg_dump命令的備份，但是因為數據庫版本的問題，已然失效。
Gitlab利用Azure進行備份，但是備份只針對了NFS服務器而沒有針對數據庫服務器。原文還提到了一個不能用的S3備份卻沒有說明原因，此處不作分析。
管理員們還急中生智，想利用一個往預發布環境同步數據的同步程序來恢復數據，但是同步一旦完成，這個空間自動就清空了。這根本就不是，也不應該是一個數據備份機制的一部分。
從數據庫管理員的角度來看，從此次事件中得到的教訓包括：
1.讓你的備份機制能夠主動反饋結果，管理員必須能夠至少知道備份是成功還是失敗;
2.讓你的備份機制能夠完整覆蓋數據庫和文件系統以及整個計算環境，而不是僅僅針對數據庫本身;
3.經常演練。上面列舉的第二、第三和第四個備份方式可行不可行，哪怕只進行過一次演練就應該發現漏洞;
4.做一個應急預案。在這次事故中看到Gitlab的響應和修復措施幾乎無章可循，完全沒有事先的規劃和設計。
從數據保護的專業角度看，雖然Gitlab號稱采用了五種備份機制，但是仔細看來，卻顯業余。鑒于此次已經發生的Gitlab事故，以及未來即將發生的“Gitlab”事故，企業和網站應該開始思考：自己的數據庫是否正在裸奔?其數據保護和容災機制是否健全?應該向哪些廠商尋求專業保護?
在軟件定義存儲解決方案方面具有16年經驗的飛康軟件公司，針對這種情況為客戶提供了數據保護和容災產品Continuous Data Protector(CDP)。
飛康CDP可以對內部數據中心和外部云(如Gitlab的S3和Azure)進行統一管理，充分利用外部云的高性價比，并可以輕松在云間靈活跳轉，實現更高的性價比和靈活性。
飛康CDP是基于磁盤的、新一代備份與容災一體化解決方案，能夠幫客戶將文件/數據庫/操作系統實現實時備份與瞬間恢復，可以在系統出現問題時迅速將數據恢復到數分鐘以前，這極大地保證了業務的連續性，同時避免出現Gitlab事故中的因備份恢復延遲導致大量數據丟失的現象。
飛康CDP備份/容災一體化解決方案，真正以快速恢復服務為第一目標。無論用戶的應用或者系統乃至數據中心發生何種意外，例如，惡意的程序破壞、文件損毀、人為誤刪誤改、操作系統宕機、硬件故障，甚至整個機房毀于意外，在飛康CDP的全面保護下，都能最大程度地保證企業數據損失(RPO)降到最低，業務中斷時間(RTO)最短。
最后，一體化的飛康CDP 備份/容災技術，使任何災難的發生都不再是致命的，用戶很輕松就能獲得備份和容災的雙重效果。
京公網安備 11010502049343號