“從刪庫到跑路”，這句程序員用來自嘲的話差點成為現(xiàn)實，所幸的是，這次刪庫的小哥沒有跑路。

2月1日，著名的代碼資源托管網(wǎng)站 Gitlab.com 的一位工程師在維護數(shù)據(jù)時不慎刪除約 300GB 的數(shù)據(jù)，至發(fā)文時仍在恢復工作中。

據(jù)雷鋒網(wǎng)了解，此次事件發(fā)生在2月1日凌晨，肇事系統(tǒng)管理員徹夜加班工作，當他疲倦不堪地進行數(shù)據(jù)庫維護時，不慎用 rm -rf 命令對 300GB 生產(chǎn)環(huán)境數(shù)據(jù)執(zhí)行了刪除操作，當他清醒過來按下 ctrl + c 來停止刪除操作時，卻只挽留了 4.5G 的數(shù)據(jù)，其余所有數(shù)據(jù)消失殆盡。

據(jù)外媒報道，此次數(shù)據(jù)丟失的并非倉庫的數(shù)據(jù)，而是和倉庫相關(guān)的 issue 以及合并請求操作。

按照常理，GitLab 應(yīng)該會對這些數(shù)據(jù)進行有效備份，然而悲催的事情發(fā)生了，GitLab.com 號稱的五重備份機制：

• 常規(guī)備份（24小時一次）

• 自動同步、LVM快照（24小時一次的）

• Azure 備份（支隊NFS啟用，數(shù)據(jù)庫無效）

• S3 備份

五大備份方法全部出現(xiàn)問題。所幸的是，仍有一個“也許可行”的6小時前的數(shù)據(jù)備份，可能夠搶救回來一部分數(shù)據(jù)。

至本文發(fā)布時，Gitlab 方面已經(jīng)試圖該方式來逐步恢復數(shù)據(jù)：

最后他們索性在 YouTube 上直播工程師恢復數(shù)據(jù)，圍觀者眾多，甚是熱鬧：

對此，程序員們評價不一，有的覺得 Gitlab 也許用了假的備份，有的感慨開夜車應(yīng)注意安全，有的吐槽運維加班苦，應(yīng)該漲工資，甚至有不少網(wǎng)友覺得應(yīng)該將2月1日設(shè)立為“世界備份日”。

最后附上直播簡介中的部分問答內(nèi)容：

* 誰干的？他（們）會被炒魷魚嗎？
他（們）只是犯了個工作失誤，不會被炒。

* 為什么數(shù)據(jù)恢復得這么慢?
因為機器的磁盤讀寫速度限制。

* 數(shù)據(jù)庫一共多大?
310GB

* 恢復數(shù)據(jù)要多長時間？有沒有預期？
至少要到 19 UTC (世界標準時間)

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。