Windows平台恢复误删数据so easy，但是linux就没那么简单了，因为没有“回收站”。BUT，如果有一天真的不小心误删了文件，那如何是好？那就借助恢复神器extundelete了。
以下均为本人虚拟机上操作，经测试，文件系统ext3/ext4均适用。
一、安装extundelete
1、需要安装依赖包，否则编译不通过
[[email protected] /]#yum install e2fsprogs* -y
2、下载并安装extundelete
下载地址：https://sourceforge.net/projects/extundelete/files/latest/download
[[email protected] /]#tar -jxvf extundelete-0.2.4.tar.bz2 [[email protected] /]#cd extundelete-0.2.4 [[email protected] /]#./configure --prefix=/usr/local/extundelete [[email protected] /]#make && make install
3、配置临时环境变量，如果永久则写到profile
[[email protected] /]#PATH=$PATH:/usr/local/extundelete/bin
4、验证是否安装成功
[[email protected] /]# extundelete -v extundelete version 0.2.4 libext2fs version 1.41.12 Processor is little endian.
二、恢复已删除数据
为方便测试，新建了一个单独的分区/dev/sdb1，挂载/reed
[[email protected] /]#mount /dev/sdb1 /reed
1、创建测试文件
[[email protected] /]# cd /reed/ [[email protected] reed]# cp ~/extundelete-0.2.4.tar.bz2 . [[email protected] reed]# echo "reed">>del.file [[email protected] reed]# ll total 132 -rw-r--r-- 1 root root 5 Mar 16 07:20 del.file -rw-r--r-- 1 root root 108472 Mar 16 07:20 extundelete-0.2.4.tar.bz2 drwx------ 2 root root 16384 Mar 16 06:45 lost+found
2、删除文件
[[email protected] reed]# rm * rm: remove regular file `del.file‘? y rm: remove regular file `extundelete-0.2.4.tar.bz2‘? y rm: cannot remove `lost+found‘: Is a directory [[email protected] reed]# ll total 16 drwx------ 2 root root 16384 Mar 16 06:45 lost+found
3、查看/reed的inode值
[[email protected] reed]# ls -id /reed2 /reed
4、卸载/reed分区
[[email protected] reed]# cd ..[[email protected] /]# umount /reed
5、恢复已删除数据
注：默认被删文件会恢复到当前目录下的RECOVERED_FILES目录
5.1先查看已删除文件
[[email protected] /]# extundelete /dev/sdb1 --inode=2 NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 8 groups loaded. Group: 0 Contents of inode 2: 0000 | ed 41 00 00 00 10 00 00 ec 98 e8 56 e9 98 e8 56 | .A.........V...V 0010 | e9 98 e8 56 00 00 00 00 00 00 03 00 08 00 00 00 | ...V............ 0020 | 00 00 00 00 00 00 00 00 41 02 00 00 00 00 00 00 | ........A....... 0030 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0040 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0050 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0060 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0080 | 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0090 | 6e 90 e8 56 00 00 00 00 00 00 00 00 00 00 00 00 | n..V............ 00a0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00b0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00c0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00d0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00e0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ Inode is Allocated File mode: 16877 Low 16 bits of Owner Uid: 0 Size in bytes: 4096 Access time: 1458084076 Creation time: 1458084073 Modification time: 1458084073 Deletion Time: 0 Low 16 bits of Group Id: 0 Links count: 3 Blocks count: 8 File flags: 0 File version (for NFS): 0 File ACL: 0 Directory ACL: 0 Fragment address: 0 Direct blocks: 577, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 Indirect block: 0 Double indirect block: 0 Triple indirect block: 0 File name | Inode number | Deleted status . 2 .. 2 lost+found 11 extundelete-0.2.4.tar.bz2 12 Deleted del.file 13 Deleted
标记为”Deleted”的文件则是被删除的文件
5.2恢复
[[email protected] /]# extundelete --restore-all /dev/sdb1 NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 8 groups loaded. Loading journal descriptors ... 23 descriptors loaded. Searching for recoverable inodes in directory / ... 2 recoverable inodes found. Looking through the directory structure for deleted files ... 0 recoverable inodes still lost. [[email protected] /]# ll RECOVERED_FILES/ total 112 -rw-r--r-- 1 root root 5 Mar 16 07:25 del.file -rw-r--r-- 1 root root 108472 Mar 16 07:25 extundelete-0.2.4.tar.bz2
5.3大功告成。
当然还有很多其它参数，如可以指定恢复某个时间点的文件。
三、延伸知识：linux系统rm删除文件的原理
转自：http://blog.csdn.net/grantlee1988/article/details/8057228
很多时候，我们都会发现，某个进程在对当前文件读写，但是我们依然能够rm， 是不是很奇怪？而windows下面，肯定会报错，”当前文件正在被使用“， 这就得从linux下面删除文件的原理说起了。
Linux是通过link的数量来控制文件删除的，只有当一个文件不存在任何link的时候，这个文件才会被删除。一般来说，每个文件都有2个link计数器:i_count 和 i_nlink。
i_count的意义是当前文件使用者（或被调用）的数量,i_nlink 的意义是介质连接的数量（硬链接的数量）；可以理解为i_count是内存引用计数器，i_nlink是磁盘的引用计数器。
当一个文件被某一个进程引用时，对应i_count数就会增加；当创建文件的硬链接的时候，对应i_nlink数就会增加。
对于删除命令rm而言，实际就是减少磁盘引用计数i_nlink。这里就会有一个问题，如果一个文件正在被某个进程调用，而用户却执行rm操作把文件删除了，那么会出现什么结果呢？当用户执行rm操作删除文件后，再执行ls或者其他文件管理命令，无法再找到这个文件了，但是调用这个删除的文件的进程却在继续正常执行，依然能够从文件中正确的读取及写入内容。这又是为什么呢？
这是因为rm操作只是将文件的i_nlink减少了，如果没其它的链接i_nlink就为0了；但由于该文件依然被进程引用，因此，此时文件对应的i_count并不为0，所以即使执行rm操作，但系统并没有真正删除这个文件，当只有i_nlink及i_count都为0的时候，这个文件才会真正被删除。也就是说，还需要解除该进程的对该文件的调用才行。
以上讲的i_nlink及i_count是文件删除的真实条件，但是当文件没有被调用时，执行了rm操作删除文件后是否还可以找回被删的文件呢？
前面说了，rm操作只是将文件的i_nlink减少了，或者说置0了，实际就是将文件名到inode的链接删除了，此时，并没有删除文件的实体即（block数据块），此时，如果及时停止机器工作，数据是可以找回的，如果此时继续写入数据，那么当新数据就可能会被分配到被删除的数据的block数据块，此时，文件就会被真正的回收了
备注：根据以上原理，实际情况会出现以下问题，web服务器磁盘空间不够了，删除了所有无用日志还是先是磁盘空间不足，但是用du -sh /*发现磁盘空间占用的远小于硬盘总大小，这就是因为只删除了一个i_nlink，而还有其他进程在使用着这些log文件，apache或者tomcat，重启再看就ok了。