“慎用rm -rf命令，除非你知道此命令带来的后果。”这是一条Linux用户守则，虽然大多数用户都明白这条语句的含义，但是我觉得还需要完善一下，为这条语句加 上一个使用前提：在你确认自己拥有清醒头脑，并且输入没有误差的时候可以使用rm -rf命令。这次惊心动魄的起因就是我将rm –rf log* 命令错误的输成了rm –rf log *，造成了当前目录下的所有项目文件全部被误删除。
ls了两回，确定自己不是眼花后开始寻找解决 办法，昔日在Windows下有很多次数据恢复经历，但在Linux下这还是第一次，在网上发现了神器extundelete，事后也证明它确实是神器， 于是马上准备下载安装，但是问题来了，数据恢复成功的铁律就是旧数据不被覆盖，开发用的Linux安装在VMware中，使用默认磁盘分区结构，只单独挂 载了/boot和/，用户数据在/home/user，无法单独umount这个目录啊，这也说明了安装时为什么最好将/home单独mount为一个设 备，找了一些资料后发现更不能轻易变更分区结构了，于是干脆就死马当活马医，准备直接安装extundelete，不直接修改/home/user的内 容，也许文件还有救。
安装extundelete：
extundelete需要依赖e2fsprogs和e2fslibs，真庆幸当初我把RHEL配置了CentOS的yum，不然又要为了依赖包耗费脑细胞了。。。
|
1
2
|
yum install e2fsprogs*
yum install e2fslibs*
|
安装完成后解压extundelete-0.2.4.tar.bz2，用三步走方法安装extundelete：
|
1
2
3
|
./configure
makemake install
|
恢复误删的文件：
先用df看一眼/挂载到哪里了，然后直接输入要恢复文件的目录：
|
1
2
3
4
5
6
7
|
[edward@www 桌面]$ df -Th
文件系统 类型 容量 已用 可用 已用%% 挂载点/dev/mapper/VolGroup-lv_root ext4 18G 6.8G 9.7G 42% /
tmpfs tmpfs 504M 420K 504M 1% /dev/shm
/dev/sda1 ext4 485M 43M 417M 10% /boot
.host:/ vmhgfs 386G 334G 53G 87% /mnt/hgfs
|
1> 恢复单个文件
[root@orclA tmp]# extundelete /dev/sdc1 --restore-file '/top/rm01.txt'
2>恢复目录
[root@orclA tmp]# extundelete /dev/sdc1 --restore-directory '/top/rm'
3>恢复整个磁盘
[root@orclA tmp]# extundelete /dev/mapper/vg_tim-lv_home --after 1481853690 --restore-all （时间戳计算：date -d "Dec 16 10:01" +%s）
extundelete会自动扫描指定目录下所有已删除的文件，这里因为我没有umount根目录，有一些文件已经被覆盖\破坏而无法恢复了，庆幸的是都不是什么重要的文件，项目的主要源文件都恢复了，这是最让我感到欣慰的。
恢复后的文件保存在当前目录下的RECOVERED_FILES目录中，不知神马原因恢复后的文件名凌乱了，具体应该说是文件名错位了，不过这已经是最好的结果了，真心感谢extundelete的作者。
事后思考：
用rm -rf时必须保持清醒的头脑，这个前面已经说过了，不然后果就是心惊肉跳，如果再因为数据恢复不了出了业务事故而丢了工作，那可太得不偿失了。从防范的角 度，不如把rm -rf这个命令换成mv .trash，google找到了一些用脚本改写rm的方法，但是实际尝试后发现不尽人意，于是找到了trash-cli命令行回收站，trash- cli能将rm与图形界面回收站结合，既直观又安全，使用方法请参考我的这篇博文。
参考资料（感谢原作者分享）：
参考：
http://blog.chinaunix.net/uid-25544300-id-3278695.html
http://my.oschina.net/fufangchun/blog/176550