警告：当误删后，不要再对服务器进行写磁盘。一、文件删除原理

在ext3/4文件系统中，inode索引节点除了存放文件属性还指向文件的block节点，是书的目录，block存放文件的实际数据，是书的每一页，文件的上级目录的block存放的是文件名及其inode节点编号，删除文件实际上是删除文件名和inode节点编号的关联以及inode节点内的指针信息，那么实际上，文件的block还在，加上ext3/4文件系统是日志文件系统，格式化时会分配一个固定大小的空间的日志文件journal，它记录创建和删除文件的记录，当删除一个文件，操作系统首先把文件inode信息和文件名称写入到journal，然后删除文件并清空inode原始数据指针。

二、有两种情况无法恢复

1)当新的数据写入到被删除文件占用的block后，原来的inode号就指向新的数据，那么这样是无法找回的。

2)当journal日志文件存满之后，会释放前面的空间，循环使用，存放最新的记录，如果删除文件的记录被覆盖，是恢复不了的。

三、恢复文件的原理

根据journal日志文件残留inode的信息，定位到相关目录，恢复残留inode对应的block。但日志文件恢复只适合小数据量的恢复，因为journal的空间有限，存放不了太多记录。对于大文件如oracle等数据库文件恢复采用逆向推算和数据文件本身特点来提取。

此列以/home分区为例。如果是根分区的数据被误删，这个恢复起来很麻烦，大概可以进单用户模式下只读方式挂载根分区，然后恢复。或者把整个硬盘取出来后，挂载到另外一台linux服务器上操作。

一、恢复ext4分区误删数据(亲自测试过，正常)

1、同步服务器时间。[root@localhost ~]#yum install -y rdate

[root@localhost ~]#rdate -s time-b.nist.gov

[root@localhost ~]#clock -w

2、安装extundelete工具。[root@localhost ~]#yum -y install e2fsprogs* gcc gcc-c++ gcc-g77

[root@localhost ~]#wget http://nchc.dl.sourceforge.net/project/extundelete/extundelete/0.2.4/extundelete-0.2.4.tar.bz2

[root@localhost ~]#tar -jxvf extundelete-0.2.4.tar.bz2

[root@localhost ~]#cd extundelete-0.2.4

[root@localhost ~]#./configure --prefix=/usr/local/extundelete

[root@localhost ~]#make && make install

[root@localhost ~]#/usr/local/extundelete/bin/extundelete --help

3、模拟误删除数据[root@localhost ~]# rm -rf /home/netdisk 误删除

4、建议先停止一些频繁读写磁盘的服务。[root@localhost ~]# for i in `chkconfig --list |grep kkmail|awk '{print $1}'`;do /etc/init.d/$i stop;done

5、恢复操作。

(1)卸载/home分区[root@localhost ~]# fuser -k /home

[root@localhost ~]# umount /home/

(2)使用extundelete查看分区上存在的文件,如下：--inode 为查找某i节点中的内容，使用2则说明为搜索，如果需要进入目录搜索，只须要指定目录I节点即可[root@localhost ~]# /usr/local/extundelete/bin/extundelete --inode 2 /dev/mapper/VolGroup-lv_home

NOTICE: Extended attributes are not restored.

Loading filesystem metadata ... 45 groups loaded.

Group: 0

Contents of inode 2:

0000 | ed 41 00 00 00 10 00 00 d5 21 9e 5a 3f 24 9e 5a | .A.......!.Z?$.Z

0010 | 3f 24 9e 5a 00 00 00 00 00 00 03 00 08 00 00 00 | ?$.Z............

0020 | 00 00 00 00 02 00 00 00 68 21 00 00 00 00 00 00 | ........h!......

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 64 61 01 9b 64 61 01 9b 68 7f 3e 58 | ....da..da..h.>X

0090 | 38 15 9e 5a 00 00 00 00 00 00 00 00 00 00 02 ea | 8..Z............

00a0 | 07 06 3c 00 00 00 00 00 21 00 00 00 00 00 00 00 | ..<.....>

00b0 | 73 65 6c 69 6e 75 78 00 00 00 00 00 00 00 00 00 | selinux.........

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 73 79 73 74 | ............syst

00e0 | 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f 72 3a 68 6f | em_u:object_r:ho

00f0 | 6d 65 5f 72 6f 6f 74 5f 74 3a 73 30 00 00 00 00 | me_root_t:s0....

Inode is Allocated

File mode: 16877

Low 16 bits of Owner Uid: 0

Size in bytes: 4096

Access time: 1520312789

Creation time: 1520313407

Modification time: 1520313407

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: 8552, 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

netdisk                                           130561         Deleted

备注：注意看Deleted。

(3)恢复数据[root@localhost ~]# /usr/local/extundelete/bin/extundelete --restore-all  /dev/mapper/VolGroup-lv_home

# --restore-all是全部恢复 ，默认全将恢复出来的文件放在当前路径 RECOVERED_FILES/ 目录下，文件名为 file.I节点号

[root@localhost ~]# /usr/local/extundelete/bin/extundelete --restore-file 文件名 /dev/mapper/VolGroup-lv_home

[root@localhost ~]# /usr/local/extundelete/bin/extundelete --restore-inode 12 /dev/mapper/VolGroup-lv_home

备注：恢复指定的时间点后被删文件

1).指定一个时间点

# date -d "Sep 4 03:09:13 2013" +%s

------------------

1378235353

------------------

2).恢复这个时间点后的文件

# /usr/local/extundelete/bin/extundelete --restore-all --after “1378235353” /dev/mapper/VolGroup-lv_home

--------------------

..........

--------------------

注:如果要恢之前的就用before参数。extundelete命令与after结合使用，在进行恢复时非常有用，可以过滤掉那太旧的文件，减小恢复压力。

6、重新挂载/home分区，并恢复数据，启动服务。

备注：还有这个恢复工具ext4magic也可以。

官方这样描述,如果您已经在ext4的文件系统中删除了文件,选extundelete是一个不错的选择,它能够恢复已删除文件的文件名及内容.

二、恢复ext3分区误删数据(没测试过，网上教程)

上面介绍的是在ext4文件格式下的文件删除后的恢复，那如果是ext3文件格式下的文件删除后想恢复，怎么办呢？

可以使用debugfs工具，这是linux系统自带工具，debugfs恢复Ext3的文件系统中被rm、rm -f 掉的文件。[root@slave-node ~]# df -T

Filesystem Type 1K-blocks Used Available Use% Mounted on

/dev/sda3 ext3 151189708 2370036 141139672 2% /

tmpfs tmpfs 32960412 0 32960412 0% /dev/shm

/dev/sda1 ext3 198337 26798 161299 15% /boot

创建一个文件[root@slave-node ~]# mkdir test

[root@slave-node ~]# echo "123456" > /root/test/test.file

删除文件[root@slave-node ~]# rm -rf /root/test/test.file

接着运用系统自带工具debugfs来恢复已删除的文件

首先打开，刚刚被删除文件所在的分区

注意上面显示的有<>尖括号内的数字就是我们要找的文件Inode号，执行logdump –i <8654024>[root@slave-node ~]# debugfs

debugfs 1.41.12 (17-May-2010)

debugfs: open /dev/sda3

debugfs: ls -d /root/test

8654023 (12) . 8519681 (4084) .. <8654024> (4072) test.file

debugfs: logdump -i 8654024

FS block 1006 logged at sequence 404351, journal block 7241

(inode block for inode 15):

Inode: 15 Type: regular Mode: 0664 Flags: 0×0 Generation: 0

User: 0 Group: 0 Size: 20

File ACL: 0 Directory ACL: 0

Links: 1 Blockcount: 8

Fragment: Address: 0 Number: 0 Size: 0

ctime: 0×48159f2d — Mon Apr 28 15:25:57 2008

atime: 0×48159f27 — Mon Apr 28 15:25:51 2008

mtime: 0×4806f070 — Thu Apr 17 12:08:40 2008

Blocks: (0+1): 102348

No magic number at block 7247: end of journal.

执行完命令后，显示了一屏信息，需要注意的是下面Blocks这一行后面的值(如上信息，需要记住Blocks这一行后面的数字102348)

输入quit，退出debugfs

debugfs: quit

[root@slave-node ~]#

执行如下命令进行恢复：[root@slave-node ~]# dd if=/dev/sda3 of=/tmp/test.file.bk bs=4096 count=1 skip=102348

1+0 records in

1+0 records out

4096 bytes (4.1 kB) copied, 0.0110028 s, 372 kB/s

最后查看tmp目录下，发现已经恢复了我们之前删除的文件内容[root@slave-node ~]# cd /tmp/

[root@slave-node tmp]# cat test.file.bk

[root@slave-node tmp]# mv test.file.bk /root/test.file

[root@slave-node tmp]# cat /root/test.file

123456

备注：还有这个恢复工具ext3grep。

如果是在ext3的文件系统中删除了文件,extundelete和ext3grep比较仍然有一些优点,extundelete分析日志文件后,能够立即恢复一个文件,ext3grep分析整个硬盘才开始恢复硬盘中的文件,ext3grep方法是是有效的从一个小分区恢复多个文件,所以相比而言,如果需要从一个大的分区中恢复文件,extundelete要快些.

三、恢复xfs分区误删数据

xfs用xfs_irecover工具恢复。

http://www.ufsexplorer.com/rdr_xfs.php

以下摘自官网。

------------------------------------------------------------

Q: Does the filesystem have an undelete capability?

There is no undelete in XFS.

However, if an inode is unlinked but neither it nor its associated data blocks get immediately re-used and overwritten, there is some small chance to recover the file from the disk.

photorec, xfs_irecover or xfsr are some tools which attempt to do this, with varying success.

There are also commercial data recovery services and closed source software like Raise Data Recovery for XFS which claims to recover data, although this has not been tested by the XFS developers.

As always, the best advice is to keep good backups.

------------------------------------------------------------