如何恢复Linux上删除的文件,第7部分
发布网友
发布时间:2022-04-24 06:30
我来回答
共1个回答
热心网友
时间:2022-04-13 21:44
与 ext2/ext3 类似,要想确定能否恢复已删除的文件,必须弄清楚文件系统在删除文件时都执行了哪些操作,磁盘的数据块中保留了哪些相关信息,以及如何从这些信息中恢复出相关数据来。
通过上一部分的介绍,我们大概也能猜测出来,在 reiserfs 文件系统中恢复已删除的文件并不容易,这是由于 reiserfs 所采用的内部数据结构所决定的:它将小文件的数据(以及大文件的部分尾部数据)与 stat 数据一起保存到 B+ 树的叶子节点中。虽然这种设计可以有效地提高空间利用率,但却给数据恢复带来了很多困难。首先,数据在叶子节点中的位置并非是一成不变的,它会随着前后数据的变化而发生移动,这会导致有些数据可能会被覆盖,因此有些数据可能根本就无法恢复。其次,B+ 树本身就是一棵动态变化的树,节点的*和合并更大程度地增加了数据恢复的难度。
对象 id 的分配和管理
在本系列文章的上一部分中,我们介绍过超级块保存在一个单独的数据块上。实际上,超级块信息的存储并不需要占用一个完整的数据块,这个数据块中空闲的部分就用来解决对象 id 的冲突和重用问题。
我们知道,在 reiserfs 文件系统中,对象 id 就像是 ext2/ext3 文件系统中的索引节点号一样,是文件的唯一标志;而在关键字中加入目录 id 就间接反应了文件系统中的目录层次关系。为了确保文件对象 id 的唯一性,必须随时能够了解可用 id 的范围。为此,reiserfs 采用了一个如下格式的二元组的数组来保存已经使用的 id 范围:
[(first used object-id, first unused object-id)]
二元组的第一项表示第一个已经使用的 object-id 值,第二项表示下一个未用的最小 object-id 值。第一个二元组的第一项总是 1,并且其中每个元素都是从小到大的顺序存放的。例如,下面是一个系统使用过程中的例子:
1, 6, 16, 17, 38, 47, 48, 56
我们可以看出,现在已经使用的对象 id 包括:1-5、16、38-46、48-55,而其他的对象 id 都是可用的。此时如果删除对象 id 为 41 的文件,则上面的数组就会变为:
1, 6, 16, 17, 38, 41, 42, 47, 48, 56
恢复单个删除文件试验
下面让我们先从一个简单的例子入手,了解磁盘数据在 reiserfs 文件系统删除文件前后的变化,并探讨能否以及如何恢复已删除的文件。
本文后面所介绍的方法大部分都需要对磁盘进行扫描,这对于在 reiserfs 文件系统中恢复已删除文件是必不可少的。为了简单起见,我们新建立了一个只有 128MB 大小的分区,并使用这个分区来进行后续实验(笔者系统中这个分区是 /dev/sda4,如果您的系统配置与此不同,请自行修改文中使用的命令和脚本)。
为了保证实验结果不会受到磁盘上历史数据的影响,我们需要使用一个全新的分区来创建文件系统。为了确保这一点,每次在创建文件系统之前,我们首先将该分区上的数据全部清 0。命令如清单 1 所示。