Windows平台恢复误删数据so easy,但是linux就没那么简单了,因为没有“回收站”。BUT,如果有一天真的不小心误删了文件,那如何是好?那就借助恢复神器extundelete了。

以下均为本人虚拟机上操作,经测试,文件系统ext3/ext4均适用。

一、安装extundelete

1、需要安装依赖包,否则编译不通过

[root@reed /]#yum install e2fsprogs* -y

2、下载并安装extundelete

下载地址:https://sourceforge.net/projects/extundelete/files/latest/download

[root@reed /]#tar -jxvf extundelete-0.2.4.tar.bz2 
[root@reed /]#cd extundelete-0.2.4
[root@reed /]#./configure --prefix=/usr/local/extundelete
[root@reed /]#make && make install

3、配置临时环境变量,如果永久则写到profile

[root@reed /]#PATH=$PATH:/usr/local/extundelete/bin

4、验证是否安装成功

[root@reed /]# extundelete -v
extundelete version 0.2.4
libext2fs version 1.41.12
Processor is little endian.

二、恢复已删除数据

为方便测试,新建了一个单独的分区/dev/sdb1,挂载/reed

[root@reed /]#mount /dev/sdb1 /reed

1、创建测试文件

[root@reed /]# cd /reed/
[root@reed reed]# cp ~/extundelete-0.2.4.tar.bz2 .
[root@reed reed]# echo "reed">>del.file
[root@reed 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、删除文件

[root@reed 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
[root@reed reed]# ll
total 16
drwx------ 2 root root 16384 Mar 16 06:45 lost+found

3、查看/reed的inode值

[root@reed reed]# ls -id /reed
2 /reed

4、卸载/reed分区

[root@reed reed]# cd ..
[root@reed /]# umount /reed

5、恢复已删除数据

注:默认被删文件会恢复到当前目录下的RECOVERED_FILES目录

5.1先查看已删除文件

[root@reed /]# 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恢复

[root@reed /]# 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.
[root@reed /]# 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了。