经历过整整两天的不断加班努力，终于恢复了妹子删除的生产服务器数据。
事情来源：今天部门刚刚入职一个新来的漂亮妹子，部门经理便安排妹子在一台生产服务器上安装Oracle数据库，妹子一边安装一边研究。自己感觉安装的有问题，就准备卸载掉重新安装。从网上找到卸载步骤，其中有一条相关删除Oracle的安装目录，命令：如果ORACLE_BASE这个变量没有赋值，就使用删除，结果妹子使用的是ROOT账户删除的，就这样误操作把整个盘的相关文件全部删除了、包括其中MySQL数据库、Tomcat等等一些东西。直接整个项目停止了。项目经理直接暴走，看新人那种自责的眼神，也不好多责怪，就开始了整个部门的找回之旅途。首先，打电话给机房，讲盘挂到其他服务器上，SSH上去查看文件全部被清。这台服务器运行的科室一个客户的生产系统，已经上线三个月了，可得尽快恢复啊，老板那边都接到投诉了。经理已经准备购买机票赶往客户哪里进行解释并且沟通说服客户，尽量把损失降到最低。于是部门这边开始各种忙活。整个项目组的人都头大，大家开始网上各种找教程资料进行误删除数据恢复。
经过不屑的寻找，还真找到一款ext3grep能够回复通过rm-rf删除的文件，刚好我们的磁盘也是ext3格式。于是有了一丝希望，赶快第一时间对盘umount，防止重新写入补删文件扇区。下载ext3grep，安装（编译安装过程也是很艰辛）。
先是执行扫描文件名命令：ext3grep/dev/vgdata/LogVol00--dump-names
这条命令直接打印出了所以被删除文件及其路径，直接开心起飞，就证明可以恢复删除的文件，妹子脸上愁容也减少不少。
但是，这款软件不能按目录恢复文件，只能执行恢复全部命令：ext3grep/dev/vgdata/LogVol00--restore-all
结果显示当前空间不足，没办法只能尝试恢复文件，居然出现部分成功部分失败的情况：ext3grep/dev/vgdata/LogVol00--restore-filevar/lib/mysql/aqsh/tb\_b\_attench.MYD
瞬间美好的心情又凉一截，能恢复几个算几个吧！说不定重要数据文件刚好在能恢复的MYD文件中。于是将所有文件名重定向到一个文件中：过滤出来所有MSQL数据库的文件名存成一个myname.txt文件。
编写脚本恢复文件如图所示：
运行了大概30分钟左右。执行了半小时，恢复了40多个文件，但是离我们需要被恢复的还有些很遥远。
将找回来的文件附到现有的数据库上，更要文件权限为后，重启Mysql.也算是找回部分数据了，但是客户重要的考勤签到数据，等没有找回。
中间又试了试另外一块工具extundelete，跟ext3grep基本一致，也是没能恢复出。
语法：extundelete/dev/vgdata/LogVol00--restore-directoryvar/lib/mysql/aqsh
看来经理还是需要订机票跟客户解释啦！
周末早在就醒了，突然灵机一动：Binlog,也不知道行不行，死马当活马医吧！去公司试试看，反正下周肯定整个部门要挨批的，加班就加班吧。
在测试服务器上进行mysqldump，恢复文件，覆盖恢复回来的文件，并给文件加权限，重启MySQL，开始了半小时的等待。我们服务器上都要求开启了Binlog,说不定通过Binlog里就可以恢复数据呢。说干就干！
从DUMP出来的文件名找到Binlog文件，一个三个：
mysql-binlogmysql-bin.mysql-bin.00
恢复一下：ext3grep/dev/vgdata/LogVol00--restore-filevar/lib/mysql/mysql-bin.00
结果失败了，再试试其他两个。
mysqlbinlog/usr/mysql-bin.00
mysql-uroot-p
执行还原命令后，这个居然成功了，赶快SCP到测试服务器。执行Binlog还原：
mysqlbinlog/usr/mysql-bin.00
mysql-uroot-p
经过漫长的等待，终于结束了。感谢上帝！终于成功了。
本次事故所用的链接见评论区。
如果满意的小伙伴可以给小编点赞