记载服务器rm -rf误删文件的恢复历程

安排一个工程师在一台生产服务器上安装Oracle,工程师边研究边安装,感觉装的不对,预备卸载从新安装。从网上找到卸载要领，其中要施行一行下令删除Oracle的安装目录，下令如下：

rm -rf $ORACLE_BASE/*

要是ORACLE_BASE这个变量没有赋值，那下令就变成了

rm -rf /*

==||，妹子运用的可是root账户啊。就这样，把整个盘的文件全部删除了，包括利用Tomcat、MySQL数据库 and so on。。。。

（mysql数据库不是在运转吗?linux能删除正在施行的文件?反正是彻底删除了，最后还剩一个tomcat的log文件，预计是文件过大，一时没有删除成功）

看着妹子自责的眼神，又是由于这事是我安排她做的，也没有跟她讲清厉害关系，没有任何培训，责任只能一个人背了，况且怎么能让美女背负这个责任呢?

打电话到机房，将盘挂到另一台服务器上，ssh上去查看文件全部被清，这台服务器运转的可是一个客户的生产系统啊，已经运转大半年了，得尽快恢复啊。于是找来脱机备份的数据库，发明备份文件只要1kb，里面只要几行熟知的mysqldump注释（难道是crontab施行的备份脚本有题目），最接尽的备份也是2013年12月份的了，真是屋漏偏逢连夜雨啊。

想起来一名向导说过的案例：当一个生产系统挂掉今后，发明所有备份都有题目，刻录的光盘也有划痕，磁带机也坏了（一个业界先辈，预计之前还用光盘做备份了），没想到今无邪的应验到我的身上了，怎么办??

部门向导晓得状况后，已经做了最坏的B规划:向导亲自带队和产品AA周日赶到客户所在的地市，星期一去向导层沟通；BB和CC去客户治理员那边想办法说服客户。。。

救命稻草--ext3grep

赶紧到网上去查材料进行误删数据恢复，还真找到一款ext3grep能够恢复通过rm -rf删除的文件，我们磁盘也是ext3格局，且网上有不少的成功案例。于是燃起了一丝但愿，赶紧对盘umount，防止从新写入补删文件扇区。下载ext3grep，安装（编译安装历程艰苦暂且不表）。

先施行扫描文件名下令：

ext3grep /dev/vgdata/LogVol00 --dump-names

打印出了所有被删除文件及途径，心中狂喜，不用施行B规划了，文件都在呢。

这款软件不能按目录恢复文件，只能施行恢复全部下令：

ext3grep /dev/vgdata/LogVol00 --restore-all

效果目前盘空间不够，没办法只能恢复文件，尝试了几个文件，竟然局部成功局部失败

ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/aqsh/tb_b_attench.MYD

心里不禁一凉，难道是删除磁盘上被写过文件了?恢复机率不大了啊，能恢复几个算几个吧，说不定重要数据文件恰好在能恢复的MYD文件中。于是先将所有文件名重定向到一个文件文件中

ext3grep /dev/vgdata/LogVol00 --dump-names >/usr/allnames.txt

过滤出来所有mysql数据库的文件名存成,mysqltbname.txt

编写脚本恢复文件：

while read LINEdo
 echo "begin to restore file " $LINE
 ext3grep /dev/vgdata/LogVol00 --restore-file $LINE if [ $? != 0 ]
 then
  echo "restore failed, exit"
  # exit 1
 fi
done < ./mysqltbname.txt

施行，大约运转了20分钟，恢复了40多个文件，但不足啊，我们将近100张表，每张表frm,myd,myi三个文件，怎么说也有300多个左右啊！！将找回来的文件附到现有数据库上，更要文件权限为777后，重新启动mysql，也算是找回一局部数据了，但客户重要的考勤签到数据、手机端上报数据（听说客户按这些数据做员工绩效的）还没找回来啊。

咋 办?中间又试了另一款工具extundelete，跟ext3grep语法根本一致，道理应当也同样了，但是听说能按目录恢复，好吧试一试。

extundelete /dev/vgdata/LogVol00 --restore-directory var/lib/mysql/aqsh

公然不出所料，恢复不出来！！！！！！！！那些文件已被毁坏了。跟向导报告，施行B规划吧。。。无奈之下下班回家（周末了，回去休息一下，想想办法吧）

灵机一动：binlog

第二天清晨一早就醒了（心里有事啊），背上电脑，去企业（这个周末算是报销了，不受批，传递，罚款，开除就不错了，还过什么周末啊）。

照旧运转ext3grep，extundelete，也就那几招啊，把系统架到测试服务器上，看看数据能不能想办法补一补吧。在测试服务器上进行mysqldump，恢复文件，遮盖恢复回来的文件，给文件加权限，重新启动mysql。

wait,wait，不是有binlog吗?我们服务都要求开启binlog，说不定能通过binlog里恢复数据呢?

于是从dump出来的文件名里找到binlog的文件，一共三个，mysql-binlog0001,mysql-bin.000009,mysql-bin.000010，恢复一下0001

ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/mysql-bin.000001

竟然失败了。。。。。。

再看另两个文件，mysql-bin.000010大约几百MB，应当靠谱一点，施行复原下令，竟然成功了！！！！！！！！！！！！！

赶紧scp到测试服务器。施行binlog复原。

mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p

输入密码，卡住了（好现象），经过漫长的期待，终于完毕了。打开利用，哦，谢谢cctv,mtv，数据回来了！！！！！！！！！！！！！！！

后记

经过此次事故，虽然数据很荣幸能找回来了，但是历程却是惊心动迫。也为本人的差错所带来的后果，给同事和向导带来的连带责任而后怕。也但愿谨记此次事故，今后不再犯一样的差错。事故反思如下：

1.本次安排MM进行服务器保护时没有提早对她进行注明厉害状况，本人也未注重，治理凌乱，流程凌乱。一个在线的生产系统，任何一个改动一定要先谋而后动。

2.主动备份涌现题目，没有任何人检查。脱机备份人员每次从服务器高低载1k的文件却从未注重。需要明白大家在工作岗亭上的责任。

3.事故产生后，没有及时发明，造成局部数据写入磁盘，造成不可恢复题目。需要编写利用监控程序，服务一旦有异样，短信告警相干责任人。

依据评论提示,再加一条:

4.不能运用root会员来操纵。应当在服务器上开设不一样权限级别的会员。

通过本次事故，几位跟这个项目和事故没有任何关系的同事，自动前来帮助，查材料，帮测试，有一名同事还帮助到晚上1点多钟进行数据恢复测试。同时产品经理在想到面向客户的庞大压力的状况下，没有忙乱而指责开发人员和具体操纵人，而让大家能静下心来想解决方案。部门向导也积极自动的帮助想办法，陪我们加班测试，实时跟踪事情进程。

通过大家的共同努力，终于事情相对圆满完毕，接下来，周一上午进行团体反思，总结经验教训，这类事故一定尽量大努力进行以免。

/**************************************传送门************************************************/

本文所用到的工具链接：

1.ext3grep: https://code.google.com/p/ext3grep/

编译安装依赖包比较多，可以到网上搜寻怎样安装。惋惜的是作者给出的howto被墙了，我FQ将how to 的pdf文档下载下来了，读完后你将会对linux的文件系统有进一步的相识。

这个工拥有一个bug，出错后不会向下施行ext3grep: init_directories.cc:534: void init_directories(): Assertion `lost_plus_found_directory_iter != all_directories.end()' failed.，从而造成恢复失败，作者放出了一个补丁，下载地址： 补丁下载 。不明确为何作者新版没有把这个补丁加进去。

2.extundelete： http://extundelete.sourceforge.net/

功能跟ext3grep差不多，道理应当也差不多。只是号称可以复原目录，我这里没有试验成功。

后记：此刻越来越多的大企业都是禁用rm 的，要是你要移除一个文件，他们会选中mv至一个垃圾文件，隔一段工夫来集中处置。以免误删导致众多囧相！

总结

以上所述是小编给大家介绍的记载服务器rm -rf误删文件的恢复历程，但愿对大家有所帮忙，要是大家有任何疑难请给我留言，小编会及时回复大家的。在此也非常谢谢大家对我们网站的支撑！