五重备份无一有效，还有哪些 rm -rf 和GitLab类似的忧伤？

DBA的悲伤，不是没有做备份，就是没有做有效的备份。日光之下，并无鲜事。

都说一个没有删过数据库的DBA，职业生涯是不完整的，不过当你删过之后，你的DBA生涯可能就完（整）了。

今天我们要讲一个做了五重备份但无一有效备份最终导致数据库恢复失败全面崩溃的故事。

今日，据GitLab.com官方网站发布声明称由于其产品数据库问题导致的网站无法正常访问。GitLab网站的主要功能如下：

GitLab是一个利用Ruby on Rails开发的开源应用程序，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。 它拥有与GitHub类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序（Wall）进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。

而针对此事件某国外媒体报道如下：

On Tuesday evening, Pacific Time, the startup issued a sobering series of tweets we've listed below. Behind the scenes, a tired sysadmin, working late at night in the Netherlands, had accidentally deleted a directory on the wrong server during a frustrating database replication process: he wiped a folder containing 300GB of live production data that was due to be replicated.

太平洋时间星期二晚上，该创业公司发布了一系列令人振奋的tweets， 幕后，一个疲惫的sysadmin，在荷兰深夜工作，在数据库复制过程中意外地删除了一个错误的服务器上的目录：他删除了一个包含300GB的实时生产数据的文件夹。

等到清醒过来紧急按下ctrl + c，只有4.5GB保留下来。然后恢复备份失败，网站已经宕了10个小时，现在还没恢复。其尝试过程如下：

300G的数据库被删成4.5G，这哥们也真是（过年喝）醉了。然而灾难却没有终止。

根据网上的信息，GitLab使用的应该是MySQL数据库，这也是300G的数据库还能够在中断删除后，剩余一部分的原因所在。现在恢复工作仍然在紧张的进行之中，他们在Twitter上正在同步信息，看起来没有到最后，就不会放弃最后的尝试，最新的信息显示，78%的数据库拷贝已经恢复出来，丢失的数据可能在6小时左右：

我的读者们可能会记得，我曾在《DBA手记4:数据安全警示录》中说过这样一句话，如果有什么事情能够让一个DBA深夜惊醒，那就是突然想起来没有做备份。果然，最需要备份的时候还真没有，据报道，Gitlab 当前所有的数据备份都是无效的。

由于没有有效的备份，目前尝试了所有5个恢复工具都没有完成恢复。在丢失数据并恢复失败后，服务器彻底崩溃。

我想每一个DBA都熟知这一条生存守则：rm是危险的。我们也多次苦口婆心地提醒，不过豪情万丈的DBA将士们并不在意。有无数的DBA们在一个草率的rm命令前栽倒。

关于数据安全的案例竟然屡见不鲜，比如1月份：炉石传说的数据回档 ，也不要以为rm不常发生，我再引用一下以前发布过的（引用自《那个删除整个网站的小伙应该知道rm是危险的》），在DBA的世界里真实发生过的一系列rm操作：

误删除Oracle软件 硬件维护人员删除归档日志的时候，把节点2的整个ORACLE_HOME都删除了。在删除的时候没有注意到目录改变了，还键盘做了一个向上的动作，刚好就是刚刚使用的 rm -rf *，然后一个下意识的动作回车就这么按下去了。 空格导致的误删除 我最难忘的：root用户在根目录下rm -rf abc *，abc和*之间有个空格，结果把OS删除了。已经成为佳话。什么事情都可能发生的。从此，整个人好像变了一样，做什么事情，都三思而后行了。 空格导致的误删除 偶的教训不是很深刻，不过意义很重大： 删除一些 trace 文件，然后就直接删除rm orcl*， 结果通过V**到生产的，网络太慢，命令刚刚慢慢的显示出来，看都没看直接按回车，结果执行的命令却是rm orcl *，因为orcl和星号中间有个空格，所以把这个目录下面所有的内容全部删除了。出了一身冷汗，试想，如过是删除数据文件目录下的内容，那立马死翘翘了到现在为止，每次都要等命令完全显示出来，从头到尾看一遍再执行。不过，大多数错误都是在很繁忙或者很疲劳的情况下发生的，呵呵，看来DBA应该多休息才是。 误删除数据文件 當時，那幾天都是很疲勞的。在開發環境作數據文件分佈調整時，先cp完某個表空間所有文件到其他地方，然後作*匹配rm了此表空間在此目錄的數據文件。但是rename時發現居然有一數據文件沒cp過來，忘了說了，此表空間是system表空間。沒辦法，開發人員明天還要使用這個環境。幸虧之前有一備份，不過當時磁盤空間不是很充裕，足足折騰了一夜才搞定!想起來都後怕哦，幸虧不是正式環境了!再以後，就很少用cp，rm了，特別是rm *，一般是此類操作用mv來完成。需要rm的東西，一般mv到一臨時目錄了，再rm了！呵呵，可能都有點謹慎過頭了哦。 脚本中误删除文件 自己写了个rman备份以及备份成功后rm旧log的shell脚本，log的目录赋值給变量，结果执行時目录赋值沒成功，该变量指向了另一個目录，结果下面的东东全没了，系统立即报错(把用户的home目录删了)。幸好当时头脑还很清醒，也没误删什么重要的数据，很快就搞定了。以后脚本中要rm某个目录的东东再也不敢用变量表示了，直接hardcode进去算了，这样也放心。另外出问题后一定要冷静，定位出问题原因后再动。  误删除目录中挂载 一次生产环境linux系统，做整个项目目录的移植，cp一份确认正常执行后直接rm原来的目录，没想到子目录中居然有mount到其他server的XX目录，结果可想而知...linux啊...... 误删除数据文件 刚进现在的公司不久时，做一个数据仓库项目，同事周日加了一天班把数据抽到一个大表空间里，大概 100G，第二天因为临时表空间增长很快，决定重建，这个 临时表空间的开头和那个大表空间名字是一样的，只是后面加了一个_temp，当时也是因为事情比较多，认为这是很简单的，结果输入名字就忘了输入_temp，把大表空间删除了，同事白加了一个星期天，虽然没影响什么进度(数据可以重抽)，但这次教训是深刻的。

日光之下，并无鲜事。根据墨菲定律，可能发生的事情就一定会发生，这是一句说老了的话，然而每次在别人的事故面前我们都自以为是诸葛，到了自己都犯低级的错误。

今日的事件，由于损失严重，至今没有恢复。为了纪念这个事件，已经有人提议，将2月1日定为“世界备份日”。

我将以前写过的几篇文章再次分享出来，给大家一个警示：

DBA生存警示：防范频发的数据误删除操作 DBA生存警示：备份级误操作案例及防范建议 DBA生存警示：系统级误删除案例及防范建议 DBA生存警示：主备环境误操作案例及防范建议 DBA生存警示：误关闭生产库案例及防范建议 DBA生存警示：业务高峰误操作案例及建议

再次警示，愿大家都能提高数据安全意识。