Gitlab.com 误删300G数据，备份失效后直播抢救过程
番茄系统家园 · 2022-04-24 03:05:29
“从删库到跑路”，这句程序员用来自嘲的话差点成为现实，所幸的是，这次删库的小哥没有跑路。
2月1日，著名的代码资源托管网站 Gitlab.com 的一位工程师在维护数据时不慎删除约 300GB 的数据，至发文时仍在恢复工作中。
据了解，此次事件发生在2月1日凌晨，肇事系统管理员彻夜加班工作，当他疲倦不堪地进行数据库维护时，不慎用 rm -rf 命令对 300GB 生产环境数据执行了删除操作，当他清醒过来按下 ctrl + c 来停止删除操作时，却只挽留了 4.5G 的数据，其余所有数据消失殆尽。
据外媒报道，此次数据丢失的并非仓库的数据，而是和仓库相关的 issue 以及合并请求操作。
按照常理，GitLab 应该会对这些数据进行有效备份，然而悲催的事情发生了，GitLab.com 号称的五重备份机制：
常规备份（24小时一次）
自动同步、LVM快照（24小时一次的）
Azure 备份（支队NFS启用，数据库无效）
S3 备份
五大备份方法全部出现问题。所幸的是，仍有一个“也许可行”的6小时前的数据备份，可能够抢救回来一部分数据。
至本文发布时，Gitlab 方面已经试图该方式来逐步恢复数据：
：
最后附上直播简介中的部分问答内容：
免责声明： 凡标注转载/编译字样内容并非本站原创，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如果你觉得本文好，欢迎推荐给朋友阅读；本文链接： https://m.nndssk.com/dngz/3511508hi65Z.html。* 谁干的？他（们）会被炒鱿鱼吗？
他（们）只是犯了个工作失误，不会被炒。* 为什么数据恢复得这么慢?
因为机器的磁盘读写速度限制。* 数据库一共多大?
310GB* 恢复数据要多长时间？有没有预期？
至少要到 19 UTC (世界标准时间)
猜你喜欢
最新应用
热门应用
