论删库从携程到Gitlab,GitLab 系统管理员 rm -rf 误删300GB 数据，备份数据均失效 - Programmer

摘要

2月1日，著名的代码资源托管网站Gitlab.com的一位工程师在维护数据时不慎删除约300GB的数据，至发文时仍在恢复工作中。

昨天朋友圈被GitLab误删数据事件给刷爆了，业务现未恢复。

　　这家号称已为超过10万家企业提供代码托管私有部署方案的初创公司，在16年9月份刚获得2000万美金的B轮融资，这样的事故必将让客户和投资人担心。

　　据说出现该事故的原因是，太平洋时间周二晚上，一名疲惫不堪的GitLab系统管理员在荷兰工作到深夜，他在令人沮丧的数据库复制过程中不小心删除了一台不该删除的服务器上的目录：他彻底删除了一个含有300GB活动生产数据的文件夹，等他反应过来，取消rm -rf命令时，已只剩下了区区4.5GB数据。上一套可能切实可行的备份是在事先六个小时所做的。

　　更要命的是，GitLab尝试了五重备份机制的恢复，但最终依然失败。GitLab 号称的五重备份机制，分别是：

常规备份（24小时做一次）
自动同步
LVM快照（24小时做一次）
Azure备份（只对 NFS 启用，对数据库无效）
S3备份

　　在国外社交网络上，甚至有人提议为了纪念这个事件，将2月1日定位“世界备份日”。

　　GitLab官网对该事件复盘，可阅读原文。

　　马后炮一下，每年总会有几起知名公司因为误操作引起的系统宕机，前有携程，今有GitLab，我相信没有曝光出来的此类事件几乎每天都在上演。

　　备份恢复在公司通常很难引起重视，大家总是存有侥幸心理，认为我们的工程师都很专业，不会误操作，我们服务器不会有硬件故障，我们的系统很安全，不会有人攻击。往往只有在吃亏上当之后才会对数据容灾重视。

　　大家一定要记住，备份恢复是两个词，备份+恢复，备份数据是否可用，还需要定期在测试环境下对其进行恢复校验。

[Programmer] 论删库从携程到Gitlab,GitLab 系统管理员 rm -rf 误删300GB 数据，备份数据均失效

友情链接自助申请入口>>