又一起 rm -rf 惨案
2月1日凌晨，源码托管平台GitLab.com发生了用著名的删除命令删除产品数据导致网站全面下线的事故，GitLab通知，称一位身处荷兰的疲惫系统管理员在进行数据库复制过程中不小心在一台错误的服务器上删除了一个目录，rm -rf 删除了一个包含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%。
圈内讨论
@黄家海兵：看来生产环境真的要改造一下rm -rf了，让它只能删空目录，如果要删目录，要用rm -f先删文件再删目录。看来是要把rm改造一下了：先把rm改个名字，再写个rm的脚本替换，脚本里面做判断，如果有人执行rm -rf，就调用rmdir去删除，这个只能删空目录。如果是其它参数就调用改过后的rm去执行。
@左耳朵耗子：这样的故障，我在亚马逊遇过一次，一个新员工错误连了线上环境，rebuild了线上数据库……。在阿里遇过至少4次这样的重大故障，都很有意思，可惜不能公开分享
@胡晓勤：看来备份管理员没做过灾难恢复演练啊，如果定期做了，就一定能发现备份方式和策略的问题。不过，在物理服务器环境下的恢复演练又慢又麻烦，没人愿意做，在虚拟化环境下就快多了。 很好奇gitlib什么虚拟化，做虚拟机备份就简单多了，出了问题，用瞬时恢复，数分钟就恢复。看样子gitlib还在物理环境下。
@VaJoy：rm是个很可怕的指令啊，想当年我是用SQL指令不小心delete了全部数据库，但好歹还留着备份文件可以恢复
本文来源：技术最前线
注册
登录
