據《The Register》報導，事情發生在UTC時間1月31日，一名位於荷蘭、徹夜加班且疲憊不堪的系統管理員，
在維護資料庫時，誤刪了正式環境資料，而當他回過神來、取消「rm -rf」刪除指令時，原有300GB的資料被刪到只剩4.5GB。
不過最令人意外的是，GitLab的5個備份機制都出問題，
包含每24小時執行一次的LVM快照和常規備份、S3、Azure中的磁碟快照（只能用於NFS伺服器、而非資料庫伺服器）和同步備份。
幸運的是，他們在臨時伺服器發現一份事件發生前6小時前的備份，好讓他們得以回復資料。
LVM快照
常規備份
S3 Azure中的磁碟快照
同步備份
目前 GitLab還沒說 為何backup 失效 .
https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
裡面提到一些為啥backup機制無效(或不能拿來用)
誤砍是Third Incident,
有點經驗的系統維護人員應該都遇過,
通常災難都是一連串的倒楣事(或者一連串的人為失誤)....XD
另外..Disk/LVM snapshot本來就對某些database沒轍,
除非是某些storage能針對一整個lun group 作snapshot
以維持一致性..
=======================================
這整個事情我覺得問題點反而不在誤砍
而是database replicate的問題
因為一開始是要處理spammer問題, 後來
"We removed a user for using a repository as some form of CDN, resulting in 47 000 IPs signing in using the same account (causing high DB load)"
, 然後導致了replicate機制無法運行, 後來才有換機器, 砍錯台等一連串事情發生....
後面也有提到這..
"The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented"
心有戚戚焉啊...XD
內文搜尋
從 APP 打開
X