ext2文件系统下恢复误删除的文件

　　该档案的位置原来是在 /var/hda/backup/home/bbs 下，我们系统的 filesystem 组态是:

root@bbs:/home/ftp/rescue# df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 396500 312769 63250 83% /
/dev/sda3 777410 537633 199615 73% /home
/dev/hda1 199047 36927 151840 20% /var/hda
/dev/hda2 1029023 490998 485710 50% /home/ftp

　　因此 /var/hda 这个 filesystem 要马上 mount 成 readonly (以下请用 root 身份):

mount -o remount,ro /var/hda

　　当然也可以直接 umount 它，但有时候可能有某些 process 正在此 filesystem下运作，您可能无法直接 umount 它。因此我选择 mount readonly。但您也可以用:

fuser -v -m /usr

　　看一下目前是那些 process 在用这个 filesystem, 然后一一砍掉，再 umount。

　　抢救步骤 II

　　执行

echo lsdel | debugfs /dev/hda1 | less

　　看一下该 filesystem 最近被砍的 inode (档案) 有那些 (为什么是 /dev/hda1? 请见上头的 df 列表)? 在这奶F档案的重要资讯，如大小、时间、属性等等。就我们的系统而言，其列示如下:

debugfs: 92 deleted inodes found.
Inode Owner Mode Size Blocks Time deleted
....................................................................
29771 0 100644 1255337 14/14 Sat Jan 30 22:37:10 1999
29772 0 100644 5161017 14/14 Sat Jan 30 22:37:10 1999
29773 0 100644 8220922 14/14 Sat Jan 30 22:37:10 1999
29774 0 100644 5431 6/6 Sat Jan 30 22:37:10 1999

　　请注意!我们必须要在档案大小、被砍时间等资讯中判断出要救回的档案是那一个。在此，我们要救回 29773 这个 inode。

　　抢救步骤 III

　　执行

echo "stat <29773>" | debugfs /dev/hda1

　　列出该 inode 的所有资讯，如下:

debugfs: stat <29773>
Inode: 29773 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 0 Group: 0 Size: 8220922
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 16124
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x36b31916 -- Sat Jan 30 22:37:10 1999
atime: 0x36aebee4 -- Wed Jan 27 15:23:16 1999
mtime: 0x36adec25 -- Wed Jan 27 00:24:05 1999
dtime: 0x36b31916 -- Sat Jan 30 22:37:10 1999
BLOCKS:
123134 123136 123137 123138 123140 131404 131405 131406
131407 131408 131409 131 410 131411 131668
TOTAL: 14

　　现在的重点是，必须将该 inode 所指的档案，所指的 block 全部找回来。在这它?14 个 block? 不对啊! 应该要有 8000 多个 block 才对啊! 在这卯ilesystem 的「奥密」了。上头所列的前 12 个 block 是真正指到档案资料的 block, 称之为 direct block 。第 13 个称为第一阶 indirect block, 第 14 个称为第二阶 indirect block 。什么意思? 该档的资料所在的 block 位置如下:

　　各位明白吗? 第 13 个 (131411) 与第 14 个 block 其实不是 data, 而是 index,它指出接下来的 block 的位置。由于一个 block 的大小是 1024 bytes, 一个 int 在 32 位系统中是 4 bytes, 故一个 block 可以记录 256 笔资料。以 131411 block 为例，它所记录的资料即为 (在档案未砍前):

131412 131413 131414 .... 131667 (共 256 笔)

　　而这 256 个 block 就真正记录了档案资料，所以我们称为第一阶。同理，第二阶就有两个层 index, 以 131668 来说，它可能记录了:

131669 131926 132182 .... (最多有 256 笔)

　　而 131669 的 block 记录为:

131670 131671 131672 .... 131925 (共 256 笔)

　　而这 256 个 block 才是真正储存档案资料的。而我们要的，就是这些真正储存档案资料的 block 。理论上，我们只要将这些 index block 的内容全部读出来，然后照这些 index 把所有的 block 全部读到手，就能 100% 救回档案 (假设这些 block 全部没有被新档案覆写的话)。工程很大，但是可行。不幸的是，在 kernel-2.0.33, 其设计是，如果该档案被砍了，则这些 index block 全部会规零，因此我所读到的是

本新闻共4页,当前在第2页 1 2 3 4

上一篇：Linux系统下应用知识大荟萃

下一篇：Linux文件系统的反删除方法