Gitlab.com 误删300G数据,备份失效后直播抢救过程

  • 时间:
  • 浏览:0

“从删库到跑路”,这句多多程序 员用来自嘲的话差点成为现实,所幸的是,这次删库的小哥这么 跑路。

2月1日,著名的代码资源托管网站 Gitlab.com 的一位工程师在维护数据时不慎删除约 150GB 的数据,至发文时仍在恢复工作中。

据小编()了解,此次事件位于在2月1日夜深 ,肇事系统管理员彻夜加班工作,当他疲倦不堪地进行数据库维护时,不慎用 rm -rf 命令对 150GB 生产环境数据执行了删除操作,当他清醒过来按下 ctrl + c 来停止删除操作时,却只挽留了 4.5G 的数据,其余所有数据消失殆尽。

据外媒报道,此次数据丢失的并不仓库的数据,只是我和仓库相关的 issue 以及合并请求操作。

按照常理,GitLab 应该会对有有哪些数据进行有效备份,然而悲催的事情位于了,GitLab.com 号称的五重备份机制:

  • 常规备份(24小时一次)
  • 自动同步、LVM快照(24小时一次的)
  • Azure 备份(支队NFS启用,数据库无效)
  • S3 备份

五大备份法律辦法 完整总出 什么的问题。所幸的是,仍有另还还有一个多多“你说歌词 可行”的6小时前的数据备份,将会够抢救回来一次要数据。

至本文发布时,Gitlab 方面将会试图该法律辦法 来逐步恢复数据:

最后你们你们你们你们都索性在 YouTube 上直播工程师恢复数据,围观者众多,甚是热闹

对此,多多程序 员们只是我评价不一,有的我觉得 Gitlab 你说歌词 用了假的备份,有的感慨开夜车应注意安全,有的吐槽运维加班苦,应该涨工资,甚至有不少日本明星微博 我觉得应该将2月1日设立为“世界备份日”。

最后附上直播简介中的次要问答内容:

* 谁干的?他(们)会被炒鱿鱼吗?他(们)只是我烦了个工作失误,不让被炒。* 为有哪些数据恢复得这么 慢?将会机器的磁盘读写时延单位限制。* 数据库一共多大?310GB* 恢复数据要多长时间?有这么 预期?大约要到 19 UTC (世界标准时间)

,。

有好的文章希望站长之家帮助分享推广,猛戳这里我想要投稿