Gitlab.com 誤刪 300G 資料,備份失效後直播搶救過程!

「從刪庫到跑路」,這句工程師用來自嘲的話差點成為現實,所幸的是,這次刪庫的朋友沒有跑路。
評論
評論

本文來自合作媒體 雷鋒網 ,INSIDE 授權轉載

「從刪庫到跑路」,這句工程師用來自嘲的話差點成為現實,所幸的是,這次刪庫的朋友沒有跑路。

2 月 1 日,著名的程式碼資源托管網站 Gitlab.com 的一位工程師在維護資料時不慎刪除約 300GB 的資料,至截稿為止仍在恢復工作中。

據瞭解,這次事件發生在 2 月 1 日凌晨,肇事系統管理員徹夜加班工作,當他疲倦不堪地進行資料庫維護時,不慎用 rm -rf 指令刪除了 300GB 環境資料,當他清醒過來按下 ctrl + c 來停止刪除操作時,卻只挽救了 4.5G 的資料,其餘所有資料消失殆盡。但這次刪掉的並非主要資料,而是資料庫相關的 issue 以及合併請求操作。

按照常理,GitLab 應該會對這些資料進行有效備份,然而悲劇發生了,GitLab.com 號稱的五重備份機制:

  • 常規備份(24 小時一次)
  • 自動同步、LVM 快照(24 小時一次)
  • Azure 備份(支隊 NFS 啓用,資料庫無效)
  • S3 備份

五大備份方法全部出現問題。所幸的是,仍有一個「也許可行」的 6 小時前的資料備份,可能夠搶救回來一部分資料。

至本文發佈時,Gitlab 方面已經試圖這方式來逐步回復資料。

最後他們索性在 YouTube 上直播工程師恢複資料,圍觀者眾多,非常熱鬧:

但工程師們對這種行為評價不一,有的覺得 Gitlab 也許用了假的備份,有的感慨開夜車應注意安全,有的吐槽加班苦,應該漲工資,甚至有不少網友覺得應該將 2 月 1 日設立為「世界備份日」。

最後附上直播簡介中的部分問答內容:

  • 誰做的?他(們)會被炒魷魚嗎?
    他(們)只是一次工作失誤,不會被炒。
  • 為什麼資料恢復得這麼慢?
    因為機器硬碟讀寫速度限制。
  • 資料庫一共多大?
    310GB
  • 恢復資料要多長時間?有沒有預期?
    至少要到 19 UTC (世界標準時間)