300G数据被删，五重备份机制回天乏术
1143次浏览
编辑于2017年02月08日 14:35:43
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，也是这次事故升级的部分原因。
结语：信息安全无小事，数据安全更是重中之重，有没有有效的备份机制，以及备份是否有效，有没有相关的技术人员，都是缺一不可。
作为全球知名的代码资源托管网站，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，也是这次事故升级的部分原因。
结语：信息安全无小事，数据安全更是重中之重，有没有有效的备份机制，以及备份是否有效，有没有相关的技术人员，都是缺一不可。
推荐阅读