<< 返回文章列表

云和恩墨专业数据恢复| 警示录:那个删除整个网站的小伙应该知道rm是危险的

2017年12月5日
盖国强
2253

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


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


image.png


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


image.png



原文是一个小伙发了一个帖子,说他执行的一条命令出了问题,原本需要传入参数的 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,把大表空间删除了,同事白加了一个星期天,虽然没影响什么进度(数据可以重抽),但这次教训是深刻的。


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


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

000.jpg