欢迎光临陕西鑫盛博海科技贸易有限公司官方网站 !

服务热线

400-029-8969 029-85262106

首页 > 新闻中心 > 行业动态

新闻中心news

300G数据被删,五重备份机制回天乏术

     发布时间:17-02-07

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

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


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


上一条:二月寿星强势来袭~

下一条:解读APS:一位强大又贴心的智能管家

香港内部玄机四字解特