（原標題：刪300G數據，備份失效后直播搶救過程）

　　本文作者：謝幺

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

　　2月1日，著名的代碼資源托管網站的一位工程師在維護數據時不慎刪除約300GB的數據，至發文時仍在恢復工作中。

　　據雷鋒網(公眾號：雷鋒網)了解，此次事件發生在2月1日凌晨，肇事系統管理員徹夜加班工作，當他疲倦不堪地進行數據庫維護時，不慎用rm -rf命令對300GB生產環境數據執行了刪除操作，當他清醒過來按下ctrl + c來停止刪除操作時，卻只挽留了4。5G的數據，其余所有數據消失殆盡。

　　據外媒報道，此次數據丟失的并非倉庫的數據，而是和倉庫相關的issue以及合并請求操作。

　　按照常理，GitLab應該會對這些數據進行有效備份，然而悲催的事情發生了，稱的五重備份機制：

　　常規備份（24小時一次）

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

　　Azure備份（支隊NFS啟用，數據庫無效）

　　S3備份

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

　　至本文發布時，Gitlab 方面已經試圖該方式來逐步恢復數據：

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

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

　　最后附上直播簡介中的部分問答內容：

　　* 誰干的？他（們）會被炒魷魚嗎？

　　他（們）只是犯了個工作失誤，不會被炒。

　　* 為什么數據恢復得這么慢？

　　因為機器的磁盤讀寫速度限制。

　　* 數據庫一共多大？

　　310GB

　　* 恢復數據要多長時間？有沒有預期？

　　至少要到19 UTC (世界標準時間)