linux ext3 恢复,linux下使用extundelete恢复ext3/ext4分区数据

Windows平台恢复误删数据so easy，可是linux就没那么简单了，由于没有“回收站”。BUT，若是有一天真的不当心误删了文件，那如何是好？那就借助恢复神器extundelete了。node

如下均为本人虚拟机上操做，经测试，文件系统ext3/ext4均适用。linux

1、安装extundeleteweb

一、须要安装依赖包，不然编译不经过apache

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

二、下载并安装extundeletewindows

[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

三、配置临时环境变量，若是永久则写到profilebash

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

四、验证是否安装成功服务器

[root@reed /]# extundelete -v

extundelete version 0.2.4

libext2fs version 1.41.12

Processor is little endian.

2、恢复已删除数据ide

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

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

一、建立测试文件

[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

二、删除文件

[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

三、查看/reed的inode值

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

2 /reed

四、卸载/reed分区

[root@reed reed]# cd ..

[root@reed /]# umount /reed

五、恢复已删除数据

注：默认被删文件会恢复到当前目录下的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大功告成。

固然还有不少其它参数，如能够指定恢复某个时间点的文件。

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了。