2月2日，當(dāng)我們依舊在享受春節(jié)假期的時(shí)候，卻不知大洋彼岸的Gitlab經(jīng)歷了一次慘痛的運(yùn)維事故。

一位操作員為解決一個(gè)惡意攻擊的問題，在工作到深夜并極度疲勞的狀態(tài)下，誤刪除了主數(shù)據(jù)庫的數(shù)據(jù)!在這位操作員意識(shí)到問題并立刻終止了移除文件夾操作，但是已經(jīng)太遲了——300GB的文件只剩下4.5GB。

Gitlab隨后試圖通過可用的備份文件用于恢復(fù)生產(chǎn)環(huán)境時(shí)，他們發(fā)現(xiàn)，采用的五種備份方式居然鬼使神差地在這一刻都失效了!最終導(dǎo)致Gitlab.com 官方網(wǎng)站宕機(jī)長達(dá)十個(gè)小時(shí)。

雖然Gitlab最終挽回了部分損失，但仍然丟失了6個(gè)小時(shí)的數(shù)據(jù)。

非常值得尊敬的是，Gitlab官方在youtube上直播了的整個(gè)恢復(fù)過程，為所有的IT運(yùn)維人員敲響警鐘：自己的運(yùn)維情況如何?如果這件事情發(fā)生在自己身上，會(huì)不會(huì)做得更好?

· GitLab使用的五種備份機(jī)制分別是：

· LVM快照(24小時(shí)做一次);

· 日常備份(24小時(shí)做一次);

· S3備份;

· Azure備份(只對(duì) NFS 啟用，對(duì)數(shù)據(jù)庫無效);

· 自動(dòng)同步;

但是當(dāng)這次事故發(fā)生時(shí)，所有備份全部無效!作為一個(gè)在數(shù)據(jù)保護(hù)領(lǐng)域工作多年的老司機(jī)，這件事引起了我強(qiáng)烈的興趣。究竟這些備份是如何失效的?對(duì)其他數(shù)據(jù)庫管理者，通過這件事情，我們能學(xué)到什么?

首先，Gitlab將LVM的復(fù)制周期設(shè)置為24小時(shí)。作為一個(gè)防止誤操作的屏障，這個(gè)周期明顯太長了。但是好在這個(gè)備份副本具有比較高的可靠性，在實(shí)在沒辦法的時(shí)候還可以指望得上。實(shí)際上Gitlab最后就是利用了LVM的復(fù)本對(duì)數(shù)據(jù)實(shí)現(xiàn)了恢復(fù)。這本應(yīng)是最終的一道屏障，事實(shí)證明，卻是可用的唯一屏障。

日常備份也是24小時(shí)進(jìn)行一次，但最后卻發(fā)現(xiàn)日常備份實(shí)際上并沒有生效。“高效運(yùn)維”公眾號(hào)的筆者認(rèn)為，這里的日常備份指的是Gitlab官方提供的命令行腳本，每天打包一次。很多數(shù)據(jù)庫高手貌似都喜歡使用命令行腳本，但是，一個(gè)備份作業(yè)是否完成是需要反饋的。命令行指令沒有完成的反饋，很容易就淹沒在各種交互信息里了，誰也不知道這個(gè)日常備份已經(jīng)有多久沒有執(zhí)行了。另外，如果如推測(cè)所言，這個(gè)備份只能保護(hù)數(shù)據(jù)庫本身，對(duì)整個(gè)計(jì)算系統(tǒng)是沒有保護(hù)的。

原文還提到了基于數(shù)據(jù)庫的pg_dump命令的備份，但是因?yàn)閿?shù)據(jù)庫版本的問題，已然失效。

Gitlab利用Azure進(jìn)行備份，但是備份只針對(duì)了NFS服務(wù)器而沒有針對(duì)數(shù)據(jù)庫服務(wù)器。原文還提到了一個(gè)不能用的S3備份卻沒有說明原因，此處不作分析。

管理員們還急中生智，想利用一個(gè)往預(yù)發(fā)布環(huán)境同步數(shù)據(jù)的同步程序來恢復(fù)數(shù)據(jù)，但是同步一旦完成，這個(gè)空間自動(dòng)就清空了。這根本就不是，也不應(yīng)該是一個(gè)數(shù)據(jù)備份機(jī)制的一部分。

從數(shù)據(jù)庫管理員的角度來看，從此次事件中得到的教訓(xùn)包括：

1.讓你的備份機(jī)制能夠主動(dòng)反饋結(jié)果，管理員必須能夠至少知道備份是成功還是失敗;

2.讓你的備份機(jī)制能夠完整覆蓋數(shù)據(jù)庫和文件系統(tǒng)以及整個(gè)計(jì)算環(huán)境，而不是僅僅針對(duì)數(shù)據(jù)庫本身;

3.經(jīng)常演練。上面列舉的第二、第三和第四個(gè)備份方式可行不可行，哪怕只進(jìn)行過一次演練就應(yīng)該發(fā)現(xiàn)漏洞;

4.做一個(gè)應(yīng)急預(yù)案。在這次事故中看到Gitlab的響應(yīng)和修復(fù)措施幾乎無章可循，完全沒有事先的規(guī)劃和設(shè)計(jì)。

從數(shù)據(jù)保護(hù)的專業(yè)角度看，雖然Gitlab號(hào)稱采用了五種備份機(jī)制，但是仔細(xì)看來，卻顯業(yè)余。鑒于此次已經(jīng)發(fā)生的Gitlab事故，以及未來即將發(fā)生的“Gitlab”事故，企業(yè)和網(wǎng)站應(yīng)該開始思考：自己的數(shù)據(jù)庫是否正在裸奔?其數(shù)據(jù)保護(hù)和容災(zāi)機(jī)制是否健全?應(yīng)該向哪些廠商尋求專業(yè)保護(hù)?

在軟件定義存儲(chǔ)解決方案方面具有16年經(jīng)驗(yàn)的飛康軟件公司，針對(duì)這種情況為客戶提供了數(shù)據(jù)保護(hù)和容災(zāi)產(chǎn)品Continuous Data Protector(CDP)。

飛康CDP可以對(duì)內(nèi)部數(shù)據(jù)中心和外部云(如Gitlab的S3和Azure)進(jìn)行統(tǒng)一管理，充分利用外部云的高性價(jià)比，并可以輕松在云間靈活跳轉(zhuǎn)，實(shí)現(xiàn)更高的性價(jià)比和靈活性。

飛康CDP是基于磁盤的、新一代備份與容災(zāi)一體化解決方案，能夠幫客戶將文件/數(shù)據(jù)庫/操作系統(tǒng)實(shí)現(xiàn)實(shí)時(shí)備份與瞬間恢復(fù)，可以在系統(tǒng)出現(xiàn)問題時(shí)迅速將數(shù)據(jù)恢復(fù)到數(shù)分鐘以前，這極大地保證了業(yè)務(wù)的連續(xù)性，同時(shí)避免出現(xiàn)Gitlab事故中的因備份恢復(fù)延遲導(dǎo)致大量數(shù)據(jù)丟失的現(xiàn)象。

飛康CDP備份/容災(zāi)一體化解決方案，真正以快速恢復(fù)服務(wù)為第一目標(biāo)。無論用戶的應(yīng)用或者系統(tǒng)乃至數(shù)據(jù)中心發(fā)生何種意外，例如，惡意的程序破壞、文件損毀、人為誤刪誤改、操作系統(tǒng)宕機(jī)、硬件故障，甚至整個(gè)機(jī)房毀于意外，在飛康CDP的全面保護(hù)下，都能最大程度地保證企業(yè)數(shù)據(jù)損失(RPO)降到最低，業(yè)務(wù)中斷時(shí)間(RTO)最短。

最后，一體化的飛康CDP 備份/容災(zāi)技術(shù)，使任何災(zāi)難的發(fā)生都不再是致命的，用戶很輕松就能獲得備份和容災(zāi)的雙重效果。