删300G数据，备份失效后直播抢救

（原标题：删300G数据，备份失效后直播抢救过程）

　　本文作者：谢幺

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

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

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

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

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

　　常规备份（24小时一次）

　　自动同步、LVM快照（24小时一次的）

　　Azure备份（支队NFS启用，数据库无效）

　　S3备份

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

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

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

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

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

　　* 谁干的？他（们）会被炒鱿鱼吗？

　　他（们）只是犯了个工作失误，不会被炒。

　　* 为什么数据恢复得这么慢？

　　因为机器的磁盘读写速度限制。

　　* 数据库一共多大？

　　310GB

　　* 恢复数据要多长时间？有没有预期？

　　至少要到19 UTC (世界标准时间)