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

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

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

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

据外媒报道，此次数据丢失的并非仓库的数据，而是和仓库相关的 issue 以及合并请求操作。

按照常理，GitLab 应该会对这些数据进行有效备份，然而悲催的事情发生了，GitLab.com 号称的五重备份机制：

五大备份方法全部出现问题。所幸的是，仍有一个“也许可行”的6小时前的数据备份，可能够抢救回来一部分数据。

至本文发布时，Gitlab 方面已经试图该方式来逐步恢复数据：

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

对此，程序员们评价不一，有的觉得 Gitlab 也许用了假的备份，有的感慨开夜车应注意安全，有的吐槽运维加班苦，应该涨工资，甚至有不少网友觉得应该将2月1日设立为“世界备份日”。

最后附上直播简介中的部分问答内容：

* 谁干的？他（们）会被炒鱿鱼吗？
他（们）只是犯了个工作失误，不会被炒。

* 为什么数据恢复得这么慢?
因为机器的磁盘读写速度限制。

* 数据库一共多大?
310GB

* 恢复数据要多长时间？有没有预期？
至少要到 19 UTC (世界标准时间)

本文作者：谢幺 本文转自雷锋网禁止二次转载，原文链接
回到过去，找回遗失的珍宝 - TiDB 的历史读功能 数据作为业务的核心，关系着整个业务的生死，所以对于数据库来说，数据的安全性是放在首位的，从宏观角度来看，安全性不仅仅在于的数据库本身足够稳定不会主动的丢失数据，有的时候更是对业务本身甚至人为失误造成损失是否有足够且便捷的应对方案，例如在游戏行业中经常遇到的反作弊(作弊玩家回档)问题，对于金融业务的审计需求等等，如果在数据库层面上提供相关机制，会让业务开发的工作量和复杂度减少很多。 传统的方案会定期备份数据，几天一次，甚至一天一次，把数据全量备份。当意外发生的时候，可以用来还原。但是用备份数据还原，代价还是非常大的，所有备份时间点后的数据都会丢失，你绝对不希望走到这一步。另外全量备份带来的存储
十年难得一遇！从数据误删到全量恢复的惊险记录 线上的数据库服务我们有完善的备份策略和恢复预案，数据即使被误删除了也是能够恢复的，误删除的数据量恢复只是时间问题。但各位同学自己部署的测试环境或者是在自己电脑中的开发环境的数据库就没有同级别的资源保障了。如果恰好你又把一些不能丢失的数据放到了这种环境中，那么建议要做定期备份，有备才能无患。
即使删了全库，保证半小时恢复 近期一篇《就这样把根目录删了！！！》引发了广泛的讨论，《如何防止根目录被删》汇总了7种防删方案。还有同学评论中反馈“不小心把库删了”，如何快速恢复删掉的数据库，是今天要讨论的话题。
MySQL备份与恢复方案验证 MySQL备份与恢复方案验证http://www.bieryun.com/3351.html mysqlbackup+xtrabackup (RHEL6X86_64) 之前针对mysql的备份做了个简单测试，与大家分享下          目前关于MySQL备份工具最流行的主要有三种 1.xtrabackup  -----Percona opensource 2.mysqlbackup -----mysql Enterprise 3.mysqldump -----mysql 自带工具 三种工具都支持热备；全备和增备。