如何使用R-Studio恢复被格式化分区内的数据

简介:


R-Studio中,格式化恢复与分区恢复的操作基本相同,唯一不同的是,由于格式化是针对一个特定的分区进行的,所以在恢复时没有必要对整个磁盘进行扫描,只需要对该分区进行扫描即可

我们将试验磁盘的第三个分区由 FAT32 格式化成 NTFS 后进行恢复演示。由于我们知道原来的文件系统为 FAT32 ,所以在扫描设置对话框的文件系统栏中,只保留 FAT 类型即可,这样可以避免一些不必要的系统开销。如果不能确定原来的文件系统是 FAT 还是 NTFS ,则需要对两种文件系统类型都进行勾选。
扫描完成后,程序会列出找到的分区。实际上,格式化后的扫描恢复相当于限定一个扫描的范围,在这个范围内寻找可能存在的分区。由于我们用于实验的磁盘进行过全盘清除数据的操作,不存在以前分区的干扰信息,所以扫描完成后只显示有一个 FAT32 分区。如图 10.73 所示。
 
可以看到,程序显示 FAT32 文件系统起始于分区的 16KB 处,其实这也是一个 FAT 表的起始位置。分区大小为 267.2MB ,对于分区大小的算法目前还不太了解,不过这并不影响我们恢复其中的数据。
在搜索到的分区上双击即可将其打开,如图 10.74 所示。
 
经过验证,数据基本上没有破坏。这也同时验证了我们前面的分析,即 FAT32文件系统格式化成高版本NTFS 后,数据恢复的可能性比较大
我们向现在的 NTFS 分区拷入部分数据后再格式化成 FAT32 ,其实也相当于将原来的 FAT32 重新进行 FAT32 格式化。回顾我们前面分析格式化恢复时所讲的内容, FAT32 的数据通常位于分区前部,高版本 NTFS 的数据通常稍靠后一些,形成前后错开的情形。将 FAT32 格式化成 NTFS 时没有破坏掉原 FAT32 FAT 表、根目录和数据。重新格式化成 FAT32 时,基本不会破坏 NTFS 的数据,但却会破坏最初 FAT32 文件系统的 FAT 表和根目录。我们可以通过这个实例同时验证 FAT32 分区重新进行 FAT32 格式化以及 NTFS 格式化成 FAT32 的恢复。
我们不再详细讲述基本的操作,但需要提醒一点,因为我们知道格式化的过程是 FAT32 NTFS FAT32 ,因此,需要找回原来的 FAT32 NTFS 中的数据,所以进行扫描设置时应该同时保留 FAT NTFS 文件系统类型选项。扫描结果如图 10.75 所示。
 
可以看到,程序找到了两个 FAT32 和一个 NTFS ,其中一个 FAT32 是根据 DBR 备份扇区的信息虚拟而成。我们双击起始位置为 0 FAT32 ,结果如图 10.76 所示。
 
 
可以看到,根目录下已经没有内容,因为使用与原 FAT32 分区相同的参数进行格式化时,新旧分区中的逻辑位置都是相同的,为根目录分配的簇恰好与原 FAT32 的根目录重合,因此原根目录内的内容被清空了,原来位于根目录中的子目录和文件的目录项都已经丢失。不过,子目录的簇空间还仍然存在,程序搜索到这种子目录空间后即为其建立一个目录,用号码做为它的目录名。子目录的簇空间中记录的下一级子目录及文件的目录项依然完好,所以可以列举出它们的名字。但如果要正确地恢复数据,依赖于它们的存储是否连续,因为 FAT 表已经不存在了。
最严重的破坏是,原来直接存放在根目录下的所有 Word 文档全部丢失了。因为它们的目录项直接存放在根目录的簇空间中,根目录被清空后,这些文件的目录项丢失,导致程序无法通过目录项得知它们的存在。这些文件只能通过 RAW 方式恢复。同样,它们能否被成功恢复也取决于存储的连续性。
我们再来看一下程序找到的NTFS文件系统,双击打开后如图10.77所示。
 
可以看到, NTFS 中的数据非常完好,说明一个高版本 NTFS 类型分区,如果数据量不是很大的话,格式化成 FAT32 后,数据被破坏的程度是有限的。
最后,按照我们前面介绍的方法将数据导出即可完成恢复。
 
本文摘自《数据重现--文件系统原理精解与数据恢复最佳实践》













本文转自老骥伏枥51CTO博客,原文链接: http://blog.51cto.com/sjhfml/130662  ,如需转载请自行联系原作者



相关文章
|
3月前
|
弹性计算 运维 Linux
存档拷贝后地图在人物不在的存档修复
存档拷贝后地图在人物不在的存档修复教学
446 0
|
9月前
|
SQL Java 关系型数据库
从系统报表页面导出20w条数据到本地只用了4秒,我是如何做到的
最近有个学弟找到我,跟我描述了以下场景: 他们公司内部管理系统上有很多报表,报表数据都有分页显示,浏览的时候速度还可以。但是每个报表在导出时间窗口稍微大一点的数据时,就异常缓慢,有时候多人一起导出时还会出现堆溢出。 他知道是因为数据全部加载到jvm内存导致的堆溢出。所以只能对时间窗口做了限制。以避免因导出过数据过大而引起的堆溢出。最终拍脑袋定下个限制为:导出的数据时间窗口不能超过1个月。
|
10月前
|
Linux PHP
php常用自建函数学习(3):格林威治标准时间、格式化(Y-m-d H:i:s)的时间、Linux时间截转换
php常用自建函数学习(3):格林威治标准时间、格式化(Y-m-d H:i:s)的时间、Linux时间截转换
82 0
L3-2 还原文件 (30 分)
L3-2 还原文件 (30 分)
52 0
L3-2 还原文件 (30 分)
|
前端开发
前端工作小结43-时间戳格式化
前端工作小结43-时间戳格式化
57 0
|
数据库
LeetCode(数据库)- 报告系统状态的连续日期
LeetCode(数据库)- 报告系统状态的连续日期
85 0