科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网安全频道Gitlab误删300G数据库的经验教训(含直播修复视频)

Gitlab误删300G数据库的经验教训(含直播修复视频)

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

GitLab因运维人员误操作导致300G数据被删除的教训值得深思,即使工作人员努力恢复,但仍丢失了6小时的部分数据。从结果看来,虽然不像事故刚发生时人们预期的网站发生灾难性事故那样,但它产生的影响并不小,所带来的教训也足够深。

作者:陈广成 来源:ZD至顶网安全频道 【原创】 2017年2月3日

关键字:IT运维 数据安全 数据库 Gitlab

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

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

 Gitlab误删300G数据库的经验教训(含直播修复视频)

这是一起由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程序员的你不妨看一看,从中你肯定会总结发现一些非常有价值的经验。我们进行了本地视频上传,不用翻墙。

 

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

 

 

邮件订阅

如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

重磅专题