如何恢复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 所示。