rm -rf 惨案：GitLab 管理员误删生产数据库

（点击上方蓝字，可快速关注我们）

GitLab 简介

GitLab 是利用 Ruby on Rails 实现的一个开源版本管理系统，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。它拥有与 GitHub 类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。

又一起 rm -rf 惨案

GitLab是在太平洋时间周二晚上发出一系列紧急通知，称一位身处荷兰的疲惫系统管理员在进行数据库复制过程中不小心在一台错误的服务器上删除了一个目录，他删除了一个包含 300GB 实时产品数据的文件夹，在取消 rm -rf 删除命令后该文件夹只剩下 4.5GB 数据。并且最近的数据还是在6小时前备份的。

Note: This incident affected the database (including issues and merge requests) but not the git repo's (repositories and wikis).

这起事故影响了问题（issue）和合并请求（merge request）、但没有影响 git 仓库数据库，wiki 也没事。

如何关注事件进展？

• GitLab 通过 Google Doc 和 monitor.gitlab.net 实时报告数据恢复进展。

• 目前 GitLab 正在YouTube上直播恢复进展：https://www.youtube.com/c/Gitlab/live

• 并且在 @gitlabstatus 公布最新恢复程度。截至 2017-02-01 22:14:01，GitLab 官方 Twitter 公布最新恢复程度已达到 78%。

圈内讨论

此人已死有事要烧纸：GitLab.com 有五重多备份机制：常规备份（24小时做一次）、自动同步、LVM快照（24小时做一次）、Azure备份（只对 NFS 启用，对数据库无效）、S3备份。总有一样好使，所以大家不要担心，只是时间问题。

云的N次方：重要系统维护的时候我的经验是必须两个人一起干活，一个做另外一个在旁边看，目的就是防止这种悲剧。当年一个公司把源码库1/2删除，花了几百万从磁盘/磁带恢复，最后损失了500多人两周的工作

@ruanyf: GitLab.com号称有五重备份机制：常规备份、自动同步、LVM快照、Azure备份、S3备份。这次事故发生时，所有备份全部无效！为了纪念这个事件，已经有人提议，将2月1日定为“世界备份日”。

黄家海兵：看来生产环境真的要改造一下rm -rf了，让它只能删空目录，如果要删目录，要用rm -f先删文件再删目录。看来是要把rm改造一下了：先把rm改个名字，再写个rm的脚本替换，脚本里面做判断，如果有人执行rm -rf，就调用rmdir去删除，这个只能删空目录。如果是其它参数就调用改过后的rm去执行。

左耳朵耗子：这样的故障，我在亚马逊遇过一次，一个新员工错误连了线上环境，rebuild了线上数据库……。在阿里遇过至少4次这样的重大故障，都很有意思，可惜不能公开分享

胡晓勤：看来备份管理员没做过灾难恢复演练啊，如果定期做了，就一定能发现备份方式和策略的问题。不过，在物理服务器环境下的恢复演练又慢又麻烦，没人愿意做，在虚拟化环境下就快多了。 很好奇gitlib什么虚拟化，做虚拟机备份就简单多了，出了问题，用瞬时恢复，数分钟就恢复。看样子gitlib还在物理环境下。

hal90：真事。当年有一哥儿们醉后做维护，指着生产库说：这个库没用了，然后就是 drop database xxx，潇洒回车，当时至少有两个人一边着看，无一人有反应，片刻后一人问：你删的哪个库？大惊，酒醒。急查hdr备机，也已被同步删除。幸亏每日零级备份能用，恢复到前一天，然后用当天逻辑日志恢复到一小时前。

VaJoy：rm是个很可怕的指令啊，想当年我是用SQL指令不小心delete了全部数据库，但好歹还留着备份文件可以恢复

参考：

Solidot、维基、Twitter、微博

觉得这条资讯有帮助？请转发给更多人

关注 技术最前线 ，看 IT 要闻