您当前的位置:首页>>技术中心>>数据恢复文章>>正文
 
一次手动恢复U盘数据
作者: 来源: 日期:2006-3-25 22:36:22  点击次数:

  某日,一个广州的网友在QQ上告知,他的u盘(128M,实际上是125M)在热拔插的时候数据丢失,无奈之下,就把u盘重新格式化了,然后用数据恢复工具(我不记得他用什么工具了)恢复以后却发现没有一个文件可以用。
      他的u盘以前和现在都是fat16格式的,重点恢复的是里边的word文档。他用QQ传给我一个数据恢复软件恢复后的文件,我看了一下。大小上了M单位。用winhex打开文件一看,数据杂乱无章,而且,好多word文档应该有的标志都没有。我的第一感觉是,他的word文档可能比较大,可能文档中夹带图片、大表格等占空间的东西,以至于保存文件是文件并未联系存储。而格式化后,很自然的,分区fat表丢失了。这时候的数据恢复是很艰难的。
       原来我的计划是针对簇链的丢失来制定的。必须面对整个分区,所以我让他把整个U盘的数据用winhex备份后传给我。我们的网速都有限,也感谢这位网友的信任。花了可能1个左右小时数据才过来。
      数据过来后,我大体看了一下数据偏移在一扇区的dbr数据,现在的分区结构是fat16,簇大小是2kB,容量125M,fat表所占扇区数目为250个,1个保留扇区,两份FAT表。这些数据都一切正常。如下图
此主题相关图片如下:
按此在新窗口浏览图片
      接着我在u盘的数据文件中用winhex查找“.”和“..”目录项,以此计算格式化前的u盘的参数。不到一秒就在文件的前边找到了一个目录项。目录项中的“.”所在的位置清楚地写明了他自身所处的簇的顺序号。如下图:


此主题相关图片如下:
按此在新窗口浏览图片

      这里的“.”目录所占的簇号位2(fat16分区通常的第一个簇)。
      继续搜索下一个目录簇。找到了,如下图:


此主题相关图片如下:
按此在新窗口浏览图片

      这里的偏移是1C8000H,簇的编号是0x63簇,而上边第2簇的偏移是44000H,计算一下:
(1C8000H-44000H)/(63H-2H)=4000H
天!他格式化之前簇的大小竟然是4000H=16kb.接下来我又验证了几个目录项,的确原来簇的大小是16k,怪不得他格式化以后用数据恢复软件找回的数据那么大,原来是数据恢复软件搞错了簇的大小。
       知道了就好办了,我在我的磁盘上分了一个fat16的分区,分的时候用win2003的磁盘管理器分成了簇大小为16K,以便于对应。其实分多大簇的分区,或者分成fat32都可以,只要简单的改动就可以移植我们的数据的。但终究不如直接分出来方便。
       分好区以后,找到新分区的第2簇地址。将网友传过来的数据文件从偏移44000H处开始选到结束,复制到新分区的第2簇地址,然后用数据恢复软件,数据就都出来了,毕竟word文档对于16k的簇大小,大多数还是连续的。

后记:可能有的数据恢复软件不设置一下直接就可以恢复的(我不知道,但这是个很容易实现的功能)。但手动作毕竟不同,心里踏实、放心得很,工具只不过是利用它的运算快,而不是他的智能。当然也希望能有我们自己的工具来配合修复工作。努力中。。。


上一篇:反黑行动之数据恢复
下一篇:纯手工恢复损坏数据

  北京总部: 4006-505-646
  上 海 部: 021-58358765
  深 圳 部: 0755-83692929
  浙 江 部: 13666673722
  其它地区: 4006-505-646

经典案例
藁城市东街百货-EFS文件解密成
中央电视台新闻评论部-苹果分
promise乔鼎硬盘阵列数据恢复成
麒麟童文化-苹果分区无法打开,
NAS 8100服务器数据恢复成功 
Liteon-重建一组RAID时,不小
濮阳市地方税务局-CHKDSK后数据
北京市海淀区华夏心理培训学校
台湾HD公司-FreeBSD Nas无法启
NCR公司-硬盘数据恢复成功 
解决方案
硬盘出现异响应急处理
raid磁盘阵列OFFLINE后的应急方
磁盘未被格式化,是否格式化数据
误GHOST、误一键恢复灾难应急方
误删除、误格式化数据灾难应急
LINUX FSCK数据出错灾难应急方
北亚数据恢复 - 联系我们 - 关于北亚 - 友情链接 - 网站地图 - RSS聚合 
版权所有 北京北亚数据恢复中心
24小时免费咨询电话:4006-505-646 或 800-810-580
公司地址:北京市海淀区永丰基地丰慧中路7号新材料创业大厦B座205室
T