“慎用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
make make 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