Linux下误删除数据时的拯救大行动记录

某日,某君,也就是我啦,进入到某台服务器,整理服务器时发现 /data目录下有db_mysql和mysql_data目录,查了mysql_data是不在使用的，

某日,某君,也就是我啦,进入到某台服务器,整理服务器时发现 /data目录下有db_mysql和mysql_data目录,查了mysql_data是不在使用的，所以想把mysql_data下的文件都删除了……
这个时候，估计也许可能脑袋锈抖，居然跑到上一层目录直接rm * -rf，这下糟了，把db_mysql也给删除了，db_mysql是在使用中的库啊！！我哭:'( :'(

哭也没用，这个时候还是想着怎么拯救吧！

拯救过程：
1、数据删除了，但mysql还在运行着，赶紧kill mysql，umount /dev/md0
2、使用网络上到处都是debugfs方式
debugfs /dev/md0

输入lsdel
理论上说这个时候这里可以看到被删除的文件，然后才有下一步的操作，可惜的是，这家伙貌似比较喜欢ext2，在ext3下没有任何东西显示，第一步拯救行动宣告失败

3、使用mc方式
yum install mc

安装完mc服务
直接输入mc
这里窗口最好小一点，不然是乱码
看到一个窗口，分别是一边显示删除文件，一边显示恢复文件（也许是这样，没做研究）
输入：
cd undel:/dev/md0

提示没有找到目录，无法chdir
继续：
cd /dev/md0

一样的结局
直接在窗口上鼠标点击进入，还是失败，第二个方法宣告失败

3、使用第三方软件ext3grep，哭诉，快OK吧，老天，再不行，我……我……被罚定啦

抱着丝丝希望开始了
安装e2fsprogs，据说必须要有e2fsprogs-libs，不然在后面ext3grep的安装会有问题。

下载ext3grep：

目前最新版本是ext3grep-0.8.0.tar.gz

安装：
cd
wget
tar zxvf ext3grep-0.8.0.tar.gz
cd ext3grep-0.8.0
./configure
make install

安装过程很简单，运行ext3grep 就知道是否安装成功了
恢复开始了
ext3grep /dev/md0 -ls -inode 2

这个是创建扫描的，不是必须的

恢复：
ext3grep /dev/md0 –restore-all
……

如果是恢复某个文件命令是：ext3grep /dev/md0 –restore-file 'filepath'

怀着忐忑的心情继续等待……

等扫描到：
Searching group 1088:
Searching group 1089:
Searching group 1090:
Searching group 1091:
Searching group 1092:
Searching group 1093:

有结果了，看截图，能恢复的都恢复了，恢复的文件在运行extgrep当前目录下的RESTORED_FILES目录下
查看一下该目录，除了某个log表的两个文件没有恢复全外，其他全部恢复

找XXX核对了一下这个log表的作用，运气好，得到的答复是这个表早已经没在使用了

把文件拷贝到相应的目录，，启动mysql，测试OK

oh，耶！！！终于成功了
感谢天感谢地，感谢党，感谢人民，感谢网龙，感谢技术部，感谢WEB组，感谢冷温和，感谢阮胖子，感谢Carlo Wood

引用别人的一句话：
“我痛哭流涕，我要再次感谢 Carlo Wood 手贱删除了他的 ~/home 目录，由此诞生了如此强大的 ext3grep，也正是因此，我才有了继续打酱油的时间。 ”