Gitlab误删300G数据库的经验教训（含直播修复视频） 原创

ZD至顶网安全频道 02月03日 综合消息：源码托管平台GitLab因运维人员误操作导致300G数据被删除的教训值得深思，即使工作人员努力恢复，但仍丢失了6小时的部分数据。

GitLab称最终受影响的用户不到1%，从结果看来，虽然不像事故刚发生时人们预期的网站发生灾难性事故那样，但它产生的影响并不小，所带来的教训也足够深。

这是一起由IT工程师人为原因引发的事故，作为同行，从网络上看，不少程序员、IT运维人员进行了反思，并对Gitlab的数据库误删事故进行了总结。

网友“Li Gong”总结了这次事故中GitLab犯的一系列错误：

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，也是这次事故升级的部分原因。

网友“王子嬴”给出了保障数据安全的5个策略建议：

1. 数据至少 3 个节点实时同步

2. 额外节点做延时 1 小时的半实时同步

3. 每天全量备份

4. 全量备份保存在两个相隔 30 公里以上的机房

5. 数据相关服务动态伸缩实例时，基础数据从全量备份副本恢复，保证备份副本可被正常使用

以保证不管是天灾还是人祸都可恢复。

Coolshell博主“左耳朵耗子”也进行了解读，此处摘取他对于备份的思考：

一个系统是需要做数据备份的，但是，你会发现，GitLab这个事中，就算所有的备份都可用，也不可避免地会有数据的丢失，或是也会有很多问题。理由如下：

备份通常来说都是周期性的，所以，如果你的数据丢失了，从你最近的备份恢复数据里，从备份时间到故障时间的数据都丢失了。

备份的数据会有版本不兼容的问题。比如，在你上次备份数据到故障期间，你对数据的scheme做了一次改动，或是你对数据做了一些调整，那么，你备份的数据就会和你线上的程序出现不兼容的情况。

有一些公司或是银行有灾备的数据中心，但是灾备的数据中心没有一天live过。等真正灾难来临需要live的时候，你就会发现，各种问题让你live不起来。你可以读一读几年前的这篇报道好好感受一下《以史为鉴，宁夏银行7月系统瘫痪最新解析》。

所以，在灾难来临的时候，你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作，但也会导致数据丢失，而且可能长期不用的备份系统很难恢复（比如应用、工具、数据的版本不兼容等问题）。

所以说，如果你要让你的备份系统随时都可以用，那么你就要让它随时都Live着，而随时都Live着的多结点系统，基本上就是一个分布式的高可用的系统。因为，数据丢失的原因有很多种，比如掉电、磁盘损坏、中病毒等等，而那些流程、规则、人肉检查、权限系统、checklist等等都只是让人不要误操作，都不管用，这个时候，你不得不用更好的技术去设计出一个高可用的系统！别无它法。

很多网友贡献了他们的智慧，虽然此类事件并不会终结，并且未来肯定会再发生，例如近期《炉石传说》数据丢失回档要比GitLab差得多。但每一次事件带来的教训和事后的经验总结值得好好思考，以降低同类事件发生概率。

除了网友们贡献的智慧，GitLab也对数据恢复的过程在YouTube进行了直播，引发超过33万网友围观，作为IT程序员的你不妨看一看，从中你肯定会总结发现一些非常有价值的经验。我们进行了本地视频上传，不用翻墙。

本文引用的网友观点如有侵权，请联系删除。