當晚 GitLab 的工程師們已經花了很長時間對抗垃圾訊息的發送者（spammer），這些大量垃圾訊息已經嚴重影響到資料庫的穩定性跟服務速度，甚至嚴重到鎖死資料庫的寫入功能。更嚴重的是二號資料庫連複製都有困難了，跟上線的一號資料庫的同步已經嚴重延遲，甚至拒絕連線一號資料庫。線上處理的工程師裡，有一位工程師的時區位於荷蘭，當時荷蘭已是深夜，身心俱疲的他決定把不聽話的二號資料庫資料全部刪除再重建。
他本意是要對二號資料庫伺服器特定目錄下 rm -rf（Unix 系的指令，不經 double check 就可以強制刪除所在目錄下的所有資料）指令，結果執行 1 秒或 2 秒後，猛然發現目標伺服器弄錯了，是正在線上服務中的一號伺服器而不是有問題的二號！
這就好像空難電影裡，雙引擎客機要處理故障的右引擎時，卻把維持飛機動力的左引擎給關掉了。
緊急取消指令後，300GB 的資料被刪到只剩下 4.5GB。而最後一個潛在可用的備份是 6 小時前手動操作的，一時之間連網站都連不進去了。根據該公司 Google docs 的維護紀錄在最新的訊息提到：「這個事件影響了網站資料庫（包括 issue 問題和 merge requests 合併請求），但不影響 git repos（git 版本管控檔案庫和 wiki 服務）。」
由於不是所有資料都遺失了，所以對用戶來說還是稍感安慰，但是該文件在「遇到的問題」（Problems Encountered）小節裡，最後總結：
「因此，換句話說，部署的 5 個不同備份／還原技術中，沒有一個能可靠地工作或第一時間還原回來，我們只能從 6 小時前有效的備份還原。」
看到這句以後，彷彿全世界所有人的臉都震驚地凍結好幾秒，這有點像鐵達尼號的沉沒是連續好幾個安全機制同時失常。GitLab 表示：
⑴ ±6 小時的資料遺失了。
⑵ 大致上，受到影響的有 4,613 個常規專案、74 個專案分叉（fork）和 350 個導入（import），總共 5,037 個項目。 由於 Git 儲存庫沒有遺失，我們可以重建這些專案在意外發生前所有的用戶／群組，但是我們無法恢復這些項目任何 issue 問題。
⑶ ±4979（所以 ±5000）註解遺失了。
⑷ 可能有 707 個用戶不見了，很難從 Kibana 日誌中確定。
⑸ 1 月 31 日 17:20 之前創建的 Webhook 被復原了，但在此時間後創建的則遺失了。
GitLab 成立於 2014 年，獲得 2,000 萬美元的風險投資，客戶包含 IBM、Macy’s、ING、NASA 、VMWare 等。在本週，這些投資者的內心恐怕比其用戶更加忐忑不安。
GitLab 這事件發生以後，突顯了幾個議題，除了網站資料備份機制的漏洞，可能還有工程師的超時工作（導致判斷失常）以及工作紀律問題：sudo rm -rf 這樣最高權限不經 double check 就強制執行的指令，在使用時應該要有適當的 sop 或更好的權限防呆。這事件反映出，除軟硬體設備外，人員的良善管理更為重要。
亡羊補牢為時不晚，GitLab 展現誠意以 YouTube 直播與 Twitter 將訊息公諸於網路，但是看來 GitLab 必須非常努力，才能挽回客戶與投資者對該公司的信心。對其他仰賴資訊科技的公司而言，相信這也是很好的借鏡。