LINUX恢复误删除文件的两种方法（部分成功）

• 当然是个人使用的机器啦。如果是服务器，要恢复就比较麻烦，及早切断其他用户什么的。
• 先查看有哪些盘。

df

1、使用extundelete

sudo extundelete /dev/sda1 --restore-directory /home/gh/文档

 恢复了很多文件。关键的文档没有成功。

 

2、使用debugfs

按照描述的办法，恢复出来的文档内容一点也不对。实际上看到3456的时候，吾就觉得不正常。怎么可能正好碰上这样的数字？还是写出来供大家参考吧。

 

• 进入恢复功能

sudo debugfs

• 打开操作的硬盘

open /dev/sda1

这个是刚才查看得到的位置。

• 列出刚刚删除的文件

ls -d /home/gh/文档

7077905  (12) .    7077890  (4084) ..   
<7078322> (52) .~lock.GH智能系统安装步骤.odt#   
<7083452> (4020) GH智能系统安装步骤.odt   
<7088970> (3976) gh_gstsink.cpp   

• 查看文件信息

logdump -i <7083452>

Inode 7083452 is at group 864, block 28311757, offset 3456
Journal starts at block 1, transaction 25167
  FS block 28311757 logged at sequence 25332, journal block 2597 (flags 0x2)
    (inode block for inode 7083452):
    Inode: 7083452   Type: bad type        Mode:  0040   Flags: 0x0
    Generation: 0    Version: 0x000103e8:00000000
    User:     0   Group:     0   Size: -336554028
    File ACL: 0    Directory ACL: 0
    Links: 0   Blockcount: 0
    Fragment:  Address: 0    Number: 0    Size: 0
     ctime: 0xebf097d4:00006d0c -- Thu Jun  9 07:14:28 2095
     atime: 0xebf097d4:5ba8dca2 -- Thu Jun  9 07:14:28 2095
     mtime: 0x5ba8dc79:5ba8dc7a -- Mon Sep 24 20:45:45 2018
    crtime: 0x5ba8dca2:00000000 -- Mon Sep 24 20:46:26 2018
    dtime: 0xebf097d4 -- Thu Jun  9 07:14:28 2095
Size of extra inode fields: 33152
invalid inode->i_extra_isize (33152)
    Blocks:  
No magic number at block 5077: end of journal.

• 导出文件数据

dd if=/dev/sda1 of=/tmp/saved  bs=3456 count=1 skip=28311757

bs:offset后的值。

skip：Block后的值。