首页 | 公司简介 | 数据恢复 | 备份服务 | 成功案例 | 技术中心 | 客户服务 | 服务报价 | 数据恢复软件 | 联系我们 | 北亚博客  
 
  北京总部: 4006-505-646
  天 津 部: 4006-505-646
  上 海 部: 4006-505-646
  深 圳 部: 4006-505-646
  广 州 部: 4006-505-646
  重 庆 部: 4006-505-646
  南 京 部: 4006-505-646
  其它地区: 4006-505-646
北亚数据恢复软件Windows专业版
三星手机数据恢复软件V1.0
北亚苹果手机数据恢复软件V2.0
北亚硬盘录像机数据恢复软件 V
北亚vmware虚拟机数据恢复软件
北亚照片数据恢复软件
北亚摄像机数据恢复软件 v2.1
北亚Sybase数据库修复软件 V2.
raid磁盘阵列应急方案
HP EVA4400/6400/8400/P6000
iphone 通讯录丢失如何恢复?
xen server 存储库(sr)损坏后
RAID6结构原理详解(北亚数据
AIX下删除LV后的现场保护和数
RAID损坏后 对数据的完整备份
您当前的位置:首页 >> 技术中心 >> 文件修复文栏 >> 正文

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




0 0 0 0 0 ..... (共 256 笔)



  哇! 没办法知道这些 data block 真正所在的位置。所以,在此我们做了一个很大的假设: 整个档案所在的 block 是连续的! 也就是我上头的例子。这也就是为什么说,只有连续 block (是指后头的 indirect block) 的档案才能完整救回,而这一点就要听天由命了。

  抢救步骤 IV

  好了,现在我们只好假设所有的档案处于连续的 block 上,现在请用http://archie.ncu.edu.tw/去找这个工具: fsgrab-1.2.tar.gz, 并将它安装起来。因为步骤很简单,故在此我就不多谈。我们要用它将所需的 block 全部抓出来。它的用法如下:


fsgrab -c count -s skip device



  其中 count 是只要 (连续) 读几个, skip 是指要从第几个开始读,例如我要从 131670 开始连续读 256 个,就这样下指令:


fsgrab -c 256 -s 131670 /dev/hda1 > recover



  现在我们就开始救档案吧! 以上头的资料,我们必须用以下的指令来救: (注意到头开的 12 个 block 并没有完全连续!!!)


fsgrab -c 1 -s 123134 /dev/hda1 > recover
fsgrab -c 3 -s 123136 /dev/hda1 >> recover
fsgrab -c 1 -s 123140 /dev/hda1 >> recover
fsgrab -c 7 -s 131404 /dev/hda1 >> recover



  这是开头的 12 个 block, 对于第一阶 indirect, 就资料来看好象是连续的 :-))


fsgrab -c 256 -s 131412 /dev/hda1 >> recover



  注意要跳过 131411, 因为它是 index block。对于第二阶 indirect, 我们 *假设* 它们都是连续的:


fsgrab -c 256 -s 131670 /dev/hda1 >> recover
fsgrab -c 256 -s 131927 /dev/hda1 >> recover
fsgrab -c 256 -s 132184 /dev/hda1 >> recover
............................................



  要一直做,直到 recover 的大小超过我们所要救回的档案大小 (8220922) 为止。要注意在这市 p心地跳过那些 index block (如 131668, 131669, 131926, 132183, ....) 了。

  抢救步骤 V

  最后一步,就是把档案「剪」出来,并看看我们救回多少了。在这戊]我们重复上述步骤,弄出来的 recover 档大小为 8294400,而我们要的大小是 8220922, 那就这样下指令:


split -b 8220922 recover rec



  则会做出两个档,一个是 recaa, 大小是 8220922, 另一个是 recab 则是剩下的大小,后者是垃圾,扔了即可。现在我们可以检查这个档案是不是「完整」的那个被误砍的档案了。由于我们的那个档案是 .tar.gz 的格式,于是我们这个方法来检查:


mv recaa recaa.tar.gz
zcat recaa.tar.gz > recaa.tar



  如果没有错误讯息,那表示成功了! 完全救回来了。但不幸的是,我们没有成功,将弄出的 recaa.tar 改名再 gzip 之后,与原来的 recaa.tar.gz 比一下大小,发现少了 1%, 表示说该档原来所在的 block 中最后有 1% 是不连续的 (或者被新写入的档案覆写了),但这已是不幸中的大幸了。

  后记

  对于在 undelete 时 *必需* 假设所有 block 连续的问题,那份 HOWTO 文件说 Linus 与其它 kernel 设计者正着手研究,看能否克服这个困难,也就是在档案砍掉时,不要将 index block 规零。我刚刚试一下 kenrel-2.2.0 的环境,发现已做到了!! 以下是一个已砍的档案的 inode data (由 debugfs 所读出):

  
debugfs: Inode: 36154 Type: regular Mode: 0600 Flags: 0x0 Version: 1
User: 0 Group: 0 Size: 2165945
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 4252
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x36b54c3b -- Mon Feb 1 14:39:55 1999
atime: 0x36b54c30 -- Mon Feb 1 14:39:44 1999
mtime: 0x36b54c30 -- Mon Feb 1 14:39:44 1999
dtime: 0x36b54c3b -- Mon Feb 1 14:39:55 1999
BLOCKS:

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

上一篇:Linux系统下应用知识大荟萃
下一篇:Linux文件系统的反删除方法
返回首页 | 联系我们 | 关于我们 | 招聘信息 | 友情链接 | 网站地图 | 合作伙伴
版权所有 北京北亚宸星科技有限公司
全国统一客服热线:4006-505-646
北京总部:北京市海淀区永丰基地丰慧中路7号新材料创业大厦B座205室
京ICP备09039053

tvxs