新闻中心

2月1日凌晨，著名的代码资源托管网站Gitlab.com一名系统管理员彻夜加班工作，当他疲倦不堪地进行数据库维护时，不慎用 rm-rf 命令对300GB生产环境数据执行了删除操作，当他清醒过来按下ctrl + c来停止删除操作时，却只挽留了4.5G的数据，其余所有数据消失殆尽。

　　作为全球知名的代码资源托管网站，GitLab.com号称的五重备份机制：

　　●常规备份(24小时一次)

　　● 同步备份(24小时一次)

　　●LVM快照(24小时一次)

　　●Azure备份(支队NFS启用，数据库无效)

　　●S3备份

　　五大备份方法全部出现问题，这运气也是没谁了。

　　经过8个小时的紧张修复，系统基本恢复正常，但是仍然有部分数据无法恢复，整个事件共造成：

　　● 6小时期间的数据遗失

　　● 4613份经常性专案、75个fork、350个import遗失，共计影响到5037份专案

　　● 4979份评论遗失

　　● 707名用户数据遗失

　　● 在1月31日17:20后新增的Webhooks遗失

　　本次事件中经验教训：

　　1.    在深夜做高风险操作

　　事件的起因是GitLab遭到攻击后，一位工程师加班到深夜维护线上环境。因为遇到了种种常规脚本没能解决的问题，不得不进行大量人工操作，于是在精力不济后出现致命失误，准备从 db1 同步到 db2 时错误的删除了 db1 的数据。

　　2.    部分备份脚本/设置没有定期维护

　　GitLab 的 PostGreSQL 本地备份和 Amazon S3 备份都没有正常工作。其中 PostGreSQL 本地备份设置在数据库版本升级后失效了，但没有人注意到。其它备份脚本也处于散落各处，长期无人维护的状态。

　　3.    部分备份方案没有覆盖到所有数据类型

　　Azure 提供了磁盘快照服务，但 GitLab 的 数据库服务器并没有使用，只在 NFS 服务器上使用了。

　　4.    部分备份方案没有保留完整数据

　　GitLab 在 Staging 环境上有一份6小时以前的数据，但其中没有保留 Webhook（STG 环境不应产生真实的 Webhook 行为）。实际上 Staging 环境本就不应该承担备份的责任，但这是 GitLab 眼下能找到的最完整历史数据了。后来他们在其它的备份中补回了 Webhook 的数据。

　　5.    备份流程没有 Monitoring 和 Alert

　　因为没有 Monitoring 和 Alert，以上这些安全隐患长期没有人发现和注意。

　　6.    备份频率不足　　

　　GitLab 的各种备份方案都是每天运行一次，从这次事件来看，对于他们来说可能还是不够。

　　7.    备份不能正确恢复/需要太长时间

　　GitLab 的 LVM 快照因为某些原因，没能正确恢复成功。从 Staging 环境恢复到 Production 环境的过程中，因为跨数据中心的网速以及 Staging 环境的磁盘速度等原因，备份数据在10个小时后还只传了一半，大大拖延了恢复进程。

　　8.    没有正确的设置维护 PostGreSQL

　　事故发生后一些第三方评论指出（参见官方事故报告附录），GitLab 没有正确的配置和使用 PostGreSQL，也是这次事故升级的部分原因。

　　结语：信息安全无小事，数据安全更是重中之重，有没有有效的备份机制，以及备份是否有效，有没有相关的技术人员，都是缺一不可。