【云和恩墨，提供7*24最专业的数据恢复（Oracle，MySQL，SQL server）服务，致力于为您的数据库系统做最后一道安全防护！服务热线：010-59007017-7030】数据恢复|数据库运维|性能优化|安全保障|Oracle培训|MySQL培训

我在很早之前写下的『DBA四大守则』其中有一条是：rm 是危险的。有无数的DBA们在一个草率的rm命令前栽倒，痛定思痛，我郑重的写下这个规则作为警示。

最近有一则新闻在网上流传，标题是『有个哥们很忧桑：弄错一个命令,他把整个公司删没了...』，在英文的网站上，这个标题是如下的样子：

原文是一个小伙发了一个帖子，说他执行的一条命令出了问题，原本需要传入参数的 rm -rf {foo}/{bar} ，因为Bug没有参数传入，Ansible自动推送所有操作在所有服务器，至少1535个客户托管的系统被全部删除。

并且要注意，他强调所有备份在同样的服务器被同时删除了，这个脚本执行前还挂接了所有备份的存储设备：

I run a small hosting provider with more or less 1535 customers and I use Ansible to automate some operations to be run on all servers. Last night I accidentally ran, on all servers, a Bash script with a rm -rf {foo}/{bar} with those variables undefined due to a bug in the code above this line.

All servers got deleted and the offsite backups too because the remote storage was mounted just before by the same script (that is a backup maintenance script).

How I can recover from a rm -rf / now in a timely manner?

虽然有人强调，这可能是该网站的一次炒作营销，但是这样的事情的确可能发生。再根据墨菲定律，可能发生的事情就一定会发生。据传言，某国内大型网站就曾经发生过，原本应该在一台服务器格式化分区的脚本，被错误的推送到所有服务器上执行。结果你知道的。

我再引用一下以前发布过的，在DBA的世界里真实发生过的一系列rm操作：

误删除Oracle软件

硬件维护人员删除归档日志的时候，把节点2的整个ORACLE_HOME都删除了。在删除的时候没有注意到目录改变了，还键盘做了一个向上的动作，刚好就是刚刚使用的 rm -rf *，然后一个下意识的动作回车就这么按下去了。

空格导致的误删除

我最难忘的：root用户在根目录下rm -rf abc *，abc和*之间有个空格，结果把OS删除了。已经成为佳话。什么事情都可能发生的。从此，整个人好像变了一样，做什么事情，都三思而后行了。

空格导致的误删除

偶的教训不是很深刻，不过意义很重大：

删除一些 trace 文件，然后就直接删除rm orcl*， 结果通过VPN到生产的，网络太慢，命令刚刚慢慢的显示出来，看都没看直接按回车，结果执行的命令却是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，把大表空间删除了，同事白加了一个星期天，虽然没影响什么进度(数据可以重抽)，但这次教训是深刻的。

上面仅仅是我们摘录的一小部分误删除案例，但是这些案例带来的影响有些是深远的。

运维人员必须保持严谨的风格，才能在复制环境中幸存下来。话又说回来，即便真的是误删除、格式化，在危机关头寻求云和恩墨的及时帮助，我们一定能够帮助你最大可能的恢复数据。删除不可怕，可怕的是你还覆盖重写几次！