rm -rf误删文件的恢复（extundelete工具的使用）

实战：extundelete恢复数据的过程

在数据被误删除后，第一时间要做的是卸载被删除数据所在的磁盘或磁盘分区，如果是系统根分区的数据遭到误删除，就需要将系统进入单用户，并且将根分区以只读模式挂载。这样做的原因很简单，因为将文件删除后，仅仅是将文件的inode结点中的扇区指针清零，实际文件还存储在磁盘上，如果磁盘以读写模式挂载，这些已删除的文件的数据块就可能被操作系统重新分配出去，在这些数据块被新的数据覆盖后，这些数据就真的丢失了，恢复工具也回力无天。所以，以只读模式挂载磁盘可以尽量降低数据块中数据被覆盖的风险，以提高恢复数据成功的比率。

6.1通过extundelete恢复单个文件

1.模拟数据误删除环境

在演示通过extundelete恢复数据之前，我们首先要模拟一个数据误删除环境，这里我们以ext3文件系统为例，在ext4文件系统下的恢复方式与此完全一样。简单的模拟操作过程如下：

[root@cloud1 ~]#mkdir /data

[root@cloud1 ~]#mkfs.ext3 /dev/sdc1

[root@cloud1 ~]#mount /dev/sdc1 /data

[root@cloud1 ~]# cp /etc/passwd /data

[root@cloud1 ~]# cp -r /app/ganglia-3.4.0 /data

[root@cloud1 ~]# mkdir /data/test

[root@cloud1 ~]# echo "extundelete test" > /data/test/mytest.txt

[root@cloud1 ~]#cd /data

[root@cloud1 data]# md5sum passwd

0715baf8f17a6c51be63b1c5c0fbe8c5 passwd

[root@cloud1 data]# md5sum test/mytest.txt

eb42e4b3f953ce00e78e11bf50652a80 test/mytest.txt

[root@cloud1 data]# rm -rf /data/*

2.卸载磁盘分区

在将数据误删除后，立刻需要做的就是卸载这块磁盘分区：

[root@cloud1 data]#cd /mnt

[root@cloud1 mnt]# umount /data

3.查询可恢复的数据信息

通过extundelete命令可以查询/dev/sdc1分区可恢复的数据信息：

[root@cloud1 /]# extundelete /dev/sdc1 –inode 2

……

File name | Inode number | Deleted status

. 2

.. 2

lost+found 11 Deleted

passwd 49153 Deleted

test 425985 Deleted

ganglia-3.4.0 245761 Deleted

根据上面的输出，标记为Deleted状态的是已经删除的文件或目录。同时还可以看到每个已删除文件的inode值，接下来就可以恢复文件了。

4.恢复单个文件

执行如下命令开始恢复文件：

[root@cloud1 /]# extundelete /dev/sdc1 –restore-file passwd

Loading filesystem metadata … 40 groups loaded.

Loading journal descriptors … 54 descriptors loaded.

Successfully restored file passwd

[root@cloud1 /]# cd RECOVERED_FILES/

[root@cloud1 RECOVERED_FILES]# ls

passwd

[root@cloud1 RECOVERED_FILES]# md5sum passwd

0715baf8f17a6c51be63b1c5c0fbe8c5 passwd

extundelete恢复单个文件的参数是“–restore-file”，这里需要注意的是，“–restore-file”后面指定的是恢复文件路径，这个路径是文件的相对路径。相对路径是相对于原来文件的存储路径而言的，比如，原来文件的存储路径是/data/passwd，那么在参数后面直接指定passwd文件即可，如果原来文件的存储路径是/data/test/mytest.txt，那么在参数后面通过“test/mytest.txt”指定即可。

在文件恢复成功后，extundelete命令默认会在执行命令的当前目录下创建一个RECOVERED_FILES目录，此目录用于存放恢复出来的文件，所以执行extundelete命令的当前目录必须是可写的。

根据上面的输出，通过md5sum命令校验，校验码与之前的完全一致，表明文件恢复成功。

6.2通过extundelete恢复单个目录

extundelete除了支持恢复单个文件，也支持恢复单个目录，在需要恢复目录时，通过 “–restore-directory”选项即可恢复指定目录的所有数据。

继续在上面模拟的误删除数据环境下操作，现在要恢复/data目录下的ganglia-3.4.0文件夹，操作如下：

[root@cloud1 mnt]# extundelete /dev/sdc1 –restore-directory /ganglia-3.4.0

Loading filesystem metadata … 40 groups loaded.

Loading journal descriptors … 247 descriptors loaded.

Searching for recoverable inodes in directory /ganglia-3.4.0 …

781 recoverable inodes found.

Looking through the directory structure for deleted files …

4 recoverable inodes still lost.

[root@cloud1 mnt]# ls

RECOVERED_FILES

[root@cloud1 mnt]# cd RECOVERED_FILES/

[root@cloud1 RECOVERED_FILES]# ls

ganglia-3.4.0

可以看到之前删除的目录ganglia-3.4.0已经成功恢复了，进入这个目录检查发现：所有文件内容和大小都正常。

6.3 通过extundelete恢复所有误删除数据

当需要恢复的数据较多时，一个个地指定文件或目录将是一个非常繁重和耗时的工作，不过，extundelete考虑到了这点，此时可以通过“–restore-all”选项来恢复所有被删除的文件或文件夹。

仍然在上面模拟的误删除数据环境下操作，现在要恢复/data目录下所有数据，操作过程如下：

[root@cloud1 mnt]# extundelete /dev/sdc1 –restore-all

Loading filesystem metadata … 40 groups loaded.

Loading journal descriptors … 247 descriptors loaded.

Searching for recoverable inodes in directory / …

781 recoverable inodes found.

Looking through the directory structure for deleted files …

0 recoverable inodes still lost.

[root@cloud1 mnt]# ls

RECOVERED_FILES

[root@cloud1 mnt]# cd RECOVERED_FILES/

[root@cloud1 RECOVERED_FILES]# ls

ganglia-3.4.0 passwd test

[root@cloud1 RECOVERED_FILES]# du -sh /mnt/RECOVERED_FILES/*

15M /mnt/RECOVERED_FILES/ganglia-3.4.0

4.0K /mnt/RECOVERED_FILES/passwd

8.0K /mnt/RECOVERED_FILES/test

可以看到所有数据全部完整地恢复了。

6.4通过extundelete恢复某个时间段的数据

有时候删除了大量的数据量，其中很多数据都是没用的，我们仅需要恢复其中的一部分数据，此时，如果采用恢复全部数据的办法，不但耗时，而且浪费资源，在这种情况下，就需要采用另外的一种恢复机制有选择地恢复，extundelete提供了“—after”“和”–before“参数，可以通过指定某个时间段，进而只恢复这个时间段内的数据。

下面通过一个简单示例，描述下如何恢复某个时间段内的数据。

我们首先假定在/data目录下有个刚刚创建的压缩文件ganglia-3.4.0.tar.gz，然后删除此文件，接着卸载/data分区，开始恢复一小时内的文件，操作如下：

[root@cloud1 ~]#cd /data/

[root@cloud1 data]# cp /app/ganglia-3.4.0.tar.gz /data

[root@cloud1 data]# date +%s

1379150309

[root@cloud1 data]# rm -rf ganglia-3.4.0.tar.gz

[root@cloud1 data]# cd /mnt

[root@cloud1 mnt]# umount /data

[root@cloud1 mnt]# date +%s

1379150340

[root@cloud1 mnt]# extundelete –after 1379146740 –restore-all /dev/sdc1

Only show and process deleted entries if they are deleted on or after 1379146740 and before 9223372036854775807.

Loading filesystem metadata … 40 groups loaded.

Loading journal descriptors … 247 descriptors loaded.

Searching for recoverable inodes in directory / …

779 recoverable inodes found.

[root@cloud1 mnt]# cd RECOVERED_FILES/

[root@cloud1 RECOVERED_FILES]# ls

ganglia-3.4.0.tar.gz

可以看到，刚才删除的文件，已经成功恢复，而在/data目录下还有很多被删除的文件却没有恢复，这就是”–after“参数控制的结果，因为/data目录下其他文件都是在一天之前删除的，而我们恢复的是一个小时之内被删除的文件，这就是没有恢复其他被删除文件的原因。

在这个操作过程中，需要注意是“–after”参数后面跟的时间是个总秒数。起算时间为“1970-01-01 00:00:00 UTC”，通过“date +%s”命令即可将当前时间转换为总秒数，因为恢复的是一个小时之内的数据，所以“1379146740”这个值就是通过“1379150340”减去“60*60=3600”获得的。

转载于:https://blog.51cto.com/ting2junshui/1729678