当发现某个分区的数据被误删除后，要做的第一件事是立刻卸载被误删除文件所在的分区，或者重新以只读方式挂载此分区。
这么做的原因其实很简单：删除一个文件，就是将文件inode节点中的扇区指针清除，同时，释放这些数据对应的数据块，而真实的文件还存留在磁盘分区中。但是这些被删除的文件不一定会一直存留在磁盘中，当这些释放的数据块被操作系统重新分配时，那些被删除的数据就会被覆盖。因此，在数据误删除后，马上卸载文件所在分区可以降低数据块中数据被覆盖的风险，进而提高成功恢复数据的机率。
实战ext3grep恢复文件
1．模拟数据误删除环境
下面通过一个模拟环境，详细介绍利用ext3grep恢复数据文件的过程。
[root@localhost /]# mkdir /disk #建立一个挂载点
[root@localhost /]# cd /data0/
[root@localhost data0]# dd if=/dev/zero of=/data0/disk1 count=102400
#模拟磁盘分区，创建一个空设备
记录了102400+0 的读入
记录了102400+0 的写出
52428800字节(52 MB)已复制，0.524595 秒，99.9 MB/秒
摘要：2．卸载磁盘分区 执行以下命令卸载磁盘分区： [root@localhost disk]# cd /opt/ #切换到/opt目录下 [root@localhost opt]# umount /disk/ #卸载模拟磁盘分区 3．查询恢复数据信息 执行如下命令，查询需要恢复的数据
[root@localhost data0]# mkfs.ext3 /data0/disk1 #将空设备格式化为ext4格式
mke2fs 1.41.12 (17-May-2010)
/data0/disk1 is not a block special device.
无论如何也要继续? (y,n) y
文件系统标签=
操作系统:Linux
块大小=1024 (log=0)
分块大小=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
12824 inodes, 51200 blocks
2560 blocks (5.00%) reserved for the super user
第一个数据块=1
Maximum filesystem blocks=52428800
7 block groups
8192 blocks per group, 8192 fragments per group
1832 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961
正在写入inode表: 完成
Creating journal (4096 blocks): 完成
Writing superblocks and filesystem accounting information: 完成
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@localhost data0]# mount -o loop /data0/disk1 /disk/ #挂载设备到/desk目录下
[root@localhost data0]# cd /disk/
[root@localhost disk]# cp /etc/profile /disk/ #复制文件到模拟磁盘分区
[root@localhost disk]# cp /boot/initrd-2.6.32-358.el6.i686kdump.img /disk/
[root@localhost disk]# echo "ext3grep test" > ext3grep.txt
[root@localhost disk]# cp /etc//hosts /disk/ext3grep
[root@localhost disk]# pwd
/disk
[root@localhost disk]# ls -al
总用量 3500
drwxr-xr-x. 3 root root 1024 9月 24 16:37 .
dr-xr-xr-x. 28 root root 4096 9月 24 16:13 ..
-rw-r--r--. 1 root root 158 9月 24 16:37 ext3grep
-rw-r--r--. 1 root root 14 9月 24 16:36 ext3grep.txt
-rw-------. 1 root root 3542202 9月 24 16:36 initrd-2.6.32-358.el6.i686kdump.img
drwx------. 2 root root 12288 9月 24 16:35 lost+found
-rw-r--r--. 1 root root 1796 9月 24 16:36 profile
[root@localhost disk]# md5sum profile #获取文件校验码
1153c583b1bf1dc7779c66af2e509a2b profile
[root@localhost disk]# md5sum initrd-2.6.32-358.el6.i686kdump.img
680caf5c9e6fce680004c921d40d9820 initrd-2.6.32-358.el6.i686kdump.img
[root@localhost disk]# md5sum ext3grep.txt
5afe55495cdb666daad667e1cd797dcb ext3grep.txt
[root@localhost disk]# rm -rf /disk/* #模拟误删除数据操作
[root@localhost disk]# ls
2．卸载磁盘分区
执行以下命令卸载磁盘分区：
[root@localhost disk]# cd /opt/ #切换到/opt目录下
[root@localhost opt]# umount /disk/ #卸载模拟磁盘分区
3．查询恢复数据信息
执行如下命令，查询需要恢复的数据信息：
[root@localhost opt]# ext3grep /data0/disk1 --ls --inode 2
执行该命令后，ext3grep就开始搜索可以恢复的数据文件信息，如下输出结果所示。
Running ext3grep version 0.10.2
WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
Number of groups: 7
Loading group metadata... done
Minimum / maximum journal block: 16616 / 20729
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1380011783 = Tue Sep 24 16:36:23 2013
Number of descriptors in journal: 67; min / max sequence numbers: 2 / 12
Inode is Allocated
Finding all blocks that might be directories.
D: block containing directory start, d: block containing more directory entries.
Each plus represents a directory start that references the same inode as a directory start that we found previously.
Searching group 0: DD
Searching group 1:
Searching group 2: +++++
Searching group 3:
Searching group 4:
Searching group 5:
Searching group 6:
Writing analysis so far to 'disk1.ext3grep.stage1'. Delete that file if you want to do this stage again.
Result of stage one:
2 inodes are referenced by one or more directory blocks, 1 of those inodes is still allocated.
1 inodes are referenced by more than one directory block, 1 of those inodes is still allocated.
0 blocks contain an extended directory.
Result of stage two:
1 of those inodes could be resolved because it is still allocated.
All directory inodes are accounted for!
Writing analysis so far to 'disk1.ext3grep.stage2'. Delete that file if you want to do this stage again.
The first block of the directory is 433.
Inode 2 is directory "".
Directory block 433:
.-- File type in dir_entry (r=regular file, d=directory, l=symlink)
| .-- D: Deleted ; R: Reallocated
Indx Next | Inode | Deletion time Mode File name
==========+==========+----------------data-from-inode------+-----------+=========
0 1 d 2 drwxr-xr-x .
1 end d 2 drwxr-xr-x ..
2 3 d 11 D 1380011904 Tue Sep 24 16:38:24 2013 drwx------ lost+found
3 end r 12 D 1380011904 Tue Sep 24 16:38:24 2013 rrw-r--r-- profile
4 end r 13 D 1380011904 Tue Sep 24 16:38:24 2013 rrw------- initrd-2.6.32-358.el6.i686kdump.img
5 end r 14 D 1380011904 Tue Sep 24 16:38:24 2013 rrw-r--r-- ext3grep.txt
6 end r 15 D 1380011904 Tue Sep 24 16:38:24 2013 rrw-r--r-- ext3grep
“ext3grep /data0/disk1 --ls --inode 2”主要用于扫描当前文件系统下所有文件的信息，包括存在的和已经删除的文件，其中含有D标识的就是已被删除的文件，如果不记得被删除的文件的名称，可以通过这种方式来获取要恢复的文件的名称。
通过下面的方式可以获取文件要恢复的路径信息。
[root@localhost opt]# ext3grep /data0/disk1 --dump-names
Running ext3grep version 0.10.2
WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
Number of groups: 7
Minimum / maximum journal block: 16616 / 20729
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1380011783 = Tue Sep 24 16:36:23 2013
Number of descriptors in journal: 67; min / max sequence numbers: 2 / 12
Loading disk1.ext3grep.stage2... done
ext3grep
ext3grep.txt
initrd-2.6.32-358.el6.i686kdump.img
lost+found
profile
4．恢复单个文件
如果要恢复被删除的某个文件，通过下面方式即可。
[root@localhost opt]# ext3grep /data0/disk1 --restore-file ext3grep.txt
Running ext3grep version 0.10.2
WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
Number of groups: 7
Minimum / maximum journal block: 16616 / 20729
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1380011783 = Tue Sep 24 16:36:23 2013
Number of descriptors in journal: 67; min / max sequence numbers: 2 / 12
Writing output to directory RESTORED_FILES/
Loading disk1.ext3grep.stage2... done
Restoring ext3grep.txt
由上面的输出可知，被删除的文件ext3grep.txt已经成功恢复。那么恢复的数据放到哪里了呢？在这段操作中，在/opt目录下执行ext3grep命令，恢复的数据文件就存放在/opt/RESTORED_FILES目录下，也就是说ext3grep会在执行恢复命令的当前目录下自动创建一个RESTORED_FILES目录，这个目录专门用于存放恢复的数据。
下面是恢复指定目录下的某个文件的操作：
[root@localhost opt]# ext3grep /data0/disk1 --restore-file ext3grep
Running ext3grep version 0.10.2
WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
Number of groups: 7
Minimum / maximum journal block: 16616 / 20729
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1380011783 = Tue Sep 24 16:36:23 2013
Number of descriptors in journal: 67; min / max sequence numbers: 2 / 12
Loading disk1.ext3grep.stage2... done
Restoring ext3grep
这里要注意的是，“--restore-file”后面指定的是恢复文件路径，这个路径应该是文件的相对路径，这里的相对路径指的是相对指定设备的路径，比如，设备/data0/diskl的挂载点是/disk，而ext3grep.txt文件就在/disk目录下，因此直接指定文件名就可以了。如果要恢复/disk/ext3grep/hosts文件，那么指定的参数应该是“ext3grep/hosts"，也就是上面代码中所指定的形式。
通过“--restore-inode”参数，只需指定文件对应的inode值即可恢复文件。操作如下（其中inode值为12的是profile文件）：
[root@localhost opt]# ext3grep /data0/disk1 --restore-inode 12
Running ext3grep version 0.10.2
WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
Number of groups: 7
Minimum / maximum journal block: 16616 / 20729
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1380011783 = Tue Sep 24 16:36:23 2013
Number of descriptors in journal: 67; min / max sequence numbers: 2 / 12
Restoring inode.12
下面进入RESTORED_FILES目录，验证文件是否成功恢复。
[root@localhost opt]# cd RESTORED_FILES/
[root@localhost RESTORED_FILES]# ls
ext3grep ext3grep.txt inode.12
[root@localhost RESTORED_FILES]# md5sum ext3grep.txt
5afe55495cdb666daad667e1cd797dcb ext3grep.txt
[root@localhost RESTORED_FILES]# md5sum inode.12
1153c583b1bf1dc7779c66af2e509a2b inode.12
根据校验结果可知，这个校验码与文件被删除之前的校验码完全一致，因此，通过这个方式恢复出来的文件是完整的。
5．恢复所有已删除数据
当需要恢复的文件较少时，通过前面介绍的指定文件的方式进行逐个恢复是可行的。但是如果要恢复很多个文件，如1OOO个以上，还采取逐个指定的方式，效率是非常低下的，此时就要利用ext3grep命令的“--restore-all"参数了。具体操作如下：
[root@localhost RESTORED_FILES]# ext3grep /data0/disk1 --restore-all
Running ext3grep version 0.10.2
WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
Number of groups: 7
Minimum / maximum journal block: 16616 / 20729
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1380011783 = Tue Sep 24 16:36:23 2013
Number of descriptors in journal: 67; min / max sequence numbers: 2 / 12
Writing output to directory RESTORED_FILES/
Finding all blocks that might be directories.
D: block containing directory start, d: block containing more directory entries.
Each plus represents a directory start that references the same inode as a directory start that we found previously.
Searching group 0: DD
Searching group 1:
Searching group 2: +++++
Searching group 3:
Searching group 4:
Searching group 5:
Searching group 6:
Writing analysis so far to 'disk1.ext3grep.stage1'. Delete that file if you want to do this stage again.
Result of stage one:
2 inodes are referenced by one or more directory blocks, 1 of those inodes is still allocated.
1 inodes are referenced by more than one directory block, 1 of those inodes is still allocated.
0 blocks contain an extended directory.
Result of stage two:
1 of those inodes could be resolved because it is still allocated.
All directory inodes are accounted for!
Writing analysis so far to 'disk1.ext3grep.stage2'. Delete that file if you want to do this stage again.
Restoring ext3grep
Restoring ext3grep.txt
Restoring initrd-2.6.32-358.el6.i686kdump.img
Restoring profile
[root@localhost RESTORED_FILES]# cd RESTORED_FILES/
[root@localhost RESTORED_FILES]# ls -al
总用量 3484
drwxr-xr-x. 3 root root 4096 9月 24 16:53 .
drwxr-xr-x. 3 root root 4096 9月 24 16:53 ..
-rw-r--r--. 1 root root 158 9月 24 16:37 ext3grep
-rw-r--r--. 1 root root 14 9月 24 16:36 ext3grep.txt
-rw-------. 1 root root 3542202 9月 24 16:36 initrd-2.6.32-358.el6.i686kdump.img
drwx------. 2 root root 4096 9月 24 16:38 lost+found
-rw-r--r--. 1 root root 1796 9月 24 16:36 profile
根据这个输出可知，“--restore-all”参数将指定存储设备中可以恢复的文件都恢复出来并放到了RESTORED_FILES目录中。“---restore-all”参数对恢复大量数据文件是非常有用的。
1486
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
