如何恢复 Linux 上删除的文件自动恢复工具 e2undel 和特殊情况的恢复冯 锐(fengruicn.ibm.com), 软件工程师, IBM王 磊(cdlwanglcn.ibm.com), 软件工程师, IBM简介： 恢复系统中删除的文件是一个非常繁琐的过程，而 e2undel 这个工具可以用来方便地恢复文件系统中已删除的文件。本文将首先讨论 e2undel 的工作原理和用法，并对之进行一些改进。然后讨论了文件系统故障、文件系统重建、磁盘物理损坏等情况下应该如何恢复数据。在本系列文章的前两部分中，我们介绍了 ext2 文件系统中各种文件在磁盘上的存储结构，以及如何利用 debugfs 工具的辅助，手工恢复这些文件的详细过程。通过这两部分的学习，我们可以看出恢复系统中删除的文件是一个非常繁琐的过程，需要非常仔细地考虑各种情况，并且要保持足够的细心，才可能把数据准确无误地恢复出来。稍有差错，就会造成数据丢失的情况。聪明的读者肯定会想，如果有一些好工具来自动或辅助完成数据的恢复过程，那简直就太好了。幸运的是，已经有人开发了这样一些工具，来简化用户的数据恢复工作，e2undel 就是其中功能最为强大的一个。自动恢复工具 e2undel回想一下，在 ext2 文件系统中删除一个文件时，该文件本身的数据并没有被真正删除，实际执行的操作如下：1 在块位图中将该文件所占用的数据块标识为可用状态。2 在索引节点位图中将该文件所占用的索引节点标识为可用状态。3 将该文件索引节点中的硬链接数目设置为 0。4 将该文件索引节点中的删除时间设置为当前时间。5 将父目录项中该文件对应项中的索引节点号设置为 0，并扩展前一项，使其包含该项所占用的空间。而索引节点中的一些关键信息（或称为元数据，包括文件属主、访问权限、文件大小、该文件所占用的数据块等）都并没有发生任何变化。因此只要知道了索引节点号，就完全可以用本系列文章介绍的技术将文件完整地从磁盘上恢复出来了，这正是 e2undel 之类的工具赖以生存的基础。然而，由于所删除的文件在目录项中对应的项中的索引节点号被清空了，因此我们就无法从索引节点中获得文件名的信息了。不过，由于文件大小、属主和删除时间信息依然能反映文件的原始信息，因此我们可以通过这些信息来帮助判断所删除的文件是哪个。e2undel 是由Oliver Diedrich 开发的一个用来恢复 ext2 文件系统中已删除文件的工具，它会遍历所检测的文件系统的索引节点表，从中找出所有被标记为删除的索引节点，并按照属主和删除时间列出这些文件。另外，e2undel 还提供了文件大小信息，并试图按照 file 命令的方式来确定文件类型。如果您使用 rm rf * 之类的命令一次删除了很多文件，这种信息就可以用来非常方便地帮助确定希望恢复的是哪些文件。在选择要恢复的文件之后，e2undel 会从磁盘上读取该文件占用的数据块（这些数据块的信息全部保存在索引节点中），并将其写入到一个新文件中。下面我们来看一下 e2undel 这个工具的详细用法。首先请从 e2undel 的主页（http:/e2undel.sourceforge.net/）上下载最新的源码包（截止到撰写本文为止，最新的版本是 0.82），并将其保存到本地文件系统中。不过这个源码包在最新的 Fedora Core 8 上编译时可能会有些问题，这是由于 ext2 文件系统内部实现中一些数据结构的变化引起来的，读者可以下载本文“下载”部分给出的补丁来修正这个问题（请下载这个补丁文件 e2undel-0.82.patch，并将其保存到与源码包相同的目录中）。要想编译 e2undel，系统中还必须安装 e2fsprogs 和 e2fsprogs-devel 这两个包，其中有编译 e2undel 所需要的一些头文件。Fedora Core 8 中自带的这两个包的版本号是 1.39-7：清单1. 确认系统中已经安装了 e2fsprogs 和 e2fsprogs-devel # rpm -qa | grep e2fsprogse2fsprogs-libs-1.39-7e2fsprogs-1.39-7e2fsprogs-devel-1.39-7现在就可以开始编译 e2undel 了：清单2. 编译 e2undel # tar -zxf e2undel-0.82.tgz # patch -p0 e2undel-0.82.patch patching file e2undel-0.82/Makefilepatching file e2undel-0.82/e2undel.hpatching file e2undel-0.82.orig/libundel.c# cd e2undel-0.82# make all编译之后会生成一个名为 e2undel 的可执行文件，其用法如下：清单3. e2undel 的用法 # ./e2undel ./e2undel 0.82usage: ./e2undel -d device -s path -a -tusage: ./e2undel -l-d: file system where to look for deleted files-s: directory where to save undeleted files-a: work on all files, not only on those listed in undel log file-t: try to determine type of deleted files w/o names, works only with -a-l: just give a list of valid files in undel log filee2undel 实际上并没有像前面介绍的使用 e2fsck 那样的方法一样真正将已经删除的文件恢复到原来的文件系统中，因为它并不会修改磁盘上 ext2 使用的内部数据结构（例如索引节点、块位图和索引节点位图）。相反，它仅仅是将所删除文件的数据恢复出来并将这些数据保存到一个新文件中。因此，-s 参数指定是保存恢复出来的文件的目录，最好是在另外一个文件系统上，否则可能会覆盖磁盘上的原有数据。如果指定了 -t 参数，e2undel 会试图读取文件的前 1KB 数据，并试图从中确定该文件的类型，其原理与系统中的 file 命令非常类似，这些信息可以帮助判断正在恢复的是什么文件。下面让我们来看一个使用 e2undel 恢复文件系统的实例。清单4. 使用 e2undel 恢复文件的实例 # ./e2undel -a -t -d /dev/sda2 -s /tmp/recover/./e2undel 0.82Trying to recover files on /dev/sda2, saving them on /tmp/recover/dev/sda2 opened for read-only access/dev/sda2 was not cleanly unmounted.Do you want wo continue (y/n)? y489600 inodes (489583 free)977956 blocks of 4096 bytes (941677 free)last mounted on Fri Dec 28 16:21:50 2007reading log file: opening log file: No such file or directoryno entries for /dev/sda2 in log filesearching for deleted inodes on /dev/sda2:|=|489600 inodes scanned, 26 deleted files found user name | 1 12 h | 2 48 h | 3 7 d | 4 30 d | 5 1 y | 6 older-+-+-+-+-+-+- root | 0 | 0 | 0 | 2 | 0 | 0 phost | 24 | 0 | 0 | 0 | 0 | 0Select user name from table or press enter to exit: rootSelect time interval (1 to 6) or press enter to exit: 4 inode size deleted at name- 13 35840 Dec 19 17:43 2007 * ASCII text 14 10485760 Dec 19 17:43 2007 * ASCII textSelect an inode listed above or press enter to go back: 13 35840 bytes written to /tmp/recover/inode-13-ASCII_textSelect an inode listed above or press enter to go back: user name | 1 12 h | 2 48 h | 3 7 d | 4 30 d | 5 1 y | 6 older-+-+-+-+-+-+- root | 0 | 0 | 0 | 2 | 0 | 0 phost | 24 | 0 | 0 | 0 | 0 | 0Select user name from table or press enter to exit: #e2undel 是一个交互式的命令，命令执行过程中需要输入的内容已经使用黑体表示出来了。从输出结果中可以看出，e2undel 一共在这个文件系统中找到了 26 个文件，其中 root 用户删除的有两个。这些文件按照删除时间的先后顺序被划分到几类中。索引节点号 13 对应的是一个 ASCII 正文的文本文件，最终被恢复到 /tmp/recover/inode-13-ASCII_text 文件中。查看一下这个文件就会发现，正是我们在本系列前两部分中删除的那个 35KB 的测试文件。利用