GitLab.com崩潰，rm -rf刪了300GB數據；要命的是，備份偏偏失效

　　這家后起之秀聲稱發展勢頭迅猛，其云已跟不上形勢，現在五個恢復工具已全部失效。

　　源代碼托管中心GitLab.com在數據遭遇丟失后崩潰，而數據丟失歸咎于它突然發現備份的內容是無效的。

　　太平洋時間周二晚上，這家初創公司發布了一系列令人不安的推特消息，我們在下面列了出來。幕后原因是，一名疲憊不堪的系統管理員在荷蘭工作到深夜，他在令人沮喪的數據庫復制過程中不小心刪除了一臺不該刪除的服務器上的目錄：他徹底刪除了一個含有300GB活動生產數據的文件夾，而這些數據還沒有完全復制過來。

　　等到他取消rm -rf命令時，已只剩下了區區4.5GB數據。上一套可能切實可行的備份是在事先六個小時所做的。

　　我們正在執行緊急數據庫維護，https://t.co/r11UmmDLDE將處于離線狀態。

　　— GitLab.com狀態（@gitlabstatus）2017年1月31日

　　我們的生產數據庫遇到了問題，正在努力恢復。

　　— GitLab.com狀態（@gitlabstatus）2017年2月1日

　　我們不小心刪除了生產數據，可能不得不從備份系統來恢復。帶活動說明（live note）的Google Doc https://t.co/EVRbHzYlk8

　　— GitLab.com狀態（@gitlabstatus）2017年2月1日

　　在最后一則推特消息說明中提到了那個Google Doc：“這起事件影響了數據庫（包括問題和合并請求），但是沒有影響git代碼庫（代碼庫和維基）。”

　　所以對用戶來說多少有點安慰，因為并非所有數據全部丟失。但是文檔在結尾處是這樣寫道：

　　所以換句話說，在部署的5套備份/復制方法中，沒有一套在可靠運行或當初設置正確。

　　此話一出，網上炸開了鍋。為了概述所犯的錯誤，這家初創公司坦率地作了如下詳述：

　　LVM快照在默認情況下每24小時做一次。在故障發生前大概6小時，YP正好手動運行了一次。

　　常規備份似乎也是每24小時做一次，不過YP還未能查清楚它們存儲在何處。據JN聲稱，這些似乎未奏效，只生成了幾個字節大小的文件。

　　SH：pg_dump似乎失效了，原因是運行的是PostgreSQL 9.2二進制代碼，而不是9.6二進制代碼。之所以會出現這種情況，是由于如果data/PG_VERSION被設成9.6，omnibus只使用Pg 9.6，但是在worker節點上，該文件并不存在。因而，它在默認情況下運行9.2，悄然失效。因而沒有SQL轉儲出現。Fog gem可能清除掉了早些時候的備份。

　　已為NFS服務器啟用了Azure中的磁盤快照，但是沒有為數據庫服務器啟用Azure中的磁盤快照。

　　一旦將數據同步到試運行環境，同步過程就消除Web勾子（webhook）。除非我們可以在過去的24小時內從常規備份中獲取這些數據，否則它們將丟失殆盡。

　　復制程序很不可靠，容易出錯，依賴幾個隨機性的外殼腳本，而且缺少完備的說明文檔。

　　我們備份到S3的內容顯然也沒有奏效：存儲桶（bucket）空空如也。

　　雪上加霜的是這個事實：GitLab去年聲稱其業務發展勢頭迅猛，其云跟不上需求，將構建和運行自己的Ceph集群。GitLab的基礎設施主管帕布羅·卡蘭扎（PabloCarranza）表示，決定部署自己的基礎設施“會讓GitLab更高效、更穩定、更可靠，因為我們對整個基礎設施將擁有更大的控制權。”

　　它此后收回了這個決定，通過推特消息告訴我們下列信息：

　　@TheRegister @gitlab將致力于讓應用系統擁有更高的性能，并在考慮選擇其他的云托管提供商。

　　— Connor Shea（@connorjshea）2017年2月1日

　　截至本文截稿時，GitLab表示它并沒有估計多久后恢復如初，但是正在努力從一臺試運行服務器來恢復，這臺試運行服務器可能“沒有Web勾子”，卻是“唯一可用的快照。”該源代碼是6小時前創建的，所以肯定丟失了部分數據。

　　去年，創辦于2014年的GitLab籌集到了2000萬美元的風投資金。眼下，那些投資者可能比用戶來得更抓狂一點。

　　如果獲得更多的信息，TheRegister會在第一時間更新本文。那位誤刪除活動數據的系統管理員認為“現在他最好別再使用超級用戶權限來運行任何命令了。