主页 / unix / 问题 / 525908
Accepted
Ryan Mills
Asked: 2019-06-20 11:59:23 +0800 CST

通过不再在日志中的 inode 恢复？

  • 772

我从 Windows 机器的 SMB 共享中删除了一个文件夹。由于零确认，整个文件夹被删除。首先运行photorec，它提取了除 1 之外的大部分文件，这是最后一个复制的文件。使用extundelete进行的进一步测试能够将整个文件夹减去 4-5 个文件。然而，一个最重要的文件再次没有恢复。查看索引节点，我可以看到恢复的文件具有顺序索引节点。所以我能够缩小确切的inode。但是，我得到以下尝试恢复该特定 inode。

Loading filesystem metadata ... 59613 groups loaded.
Loading journal descriptors ... 29932 descriptors loaded.
Unable to restore inode 60596808 (file.60596808): No undeleted copies found in the journal.

但是，当我搜索该 inode 时，我确实得到了数据：

Loading filesystem metadata ... 59613 groups loaded.
Group: 14794
Contents of inode 60596809:
0000 | e4 81 e8 03 dd df b2 1b 43 2d 08 5d 53 2d 08 5d | ........C-.]S-.]
0010 | fd 97 05 5d 53 2d 08 5d e8 03 00 00 00 00 00 00 | ...]S-.]........
0020 | 00 00 08 00 01 00 00 00 0a f3 00 00 04 00 00 00 | ................
0030 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0040 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0050 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0060 | 00 00 00 00 70 57 ff 3f 00 00 00 00 00 00 00 00 | ....pW.?........
0070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0080 | 20 00 00 00 ec e9 88 2a b0 16 cf 0f 1c 76 bb a2 |  ......*.....v..
0090 | 3c 2d 08 5d d4 64 6c a9 00 00 00 00 00 00 00 00 | <-.].dl.........
00a0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00b0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00c0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00d0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00e0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

Inode is Unallocated
File mode: 33252
Low 16 bits of Owner Uid: 1000
Size in bytes: 464707549
Access time: 1560816963
Creation time: 1560816979
Modification time: 1560647677
Deletion Time: 1560816979
Low 16 bits of Group Id: 1000
Links count: 0
Blocks count: 0
File flags: 524288
File version (for NFS): 1073698672
File ACL: 0
Directory ACL: 0
Fragment address: 0
Direct blocks: 62218, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
Indirect block: 0
Double indirect block: 0
Triple indirect block: 0

使用debugfs我试图转储 inode，但我得到的只是一个大小正确但归零的文件。

以字节、日期为单位的大小，我 99% 确定这是我需要的确切 inode 文件。这些数据基本上是缺少指向磁盘上确切位置的指针的存根吗？反正有没有使用这个inode数据来恢复实际数据？

data-recovery inode

1 个回答

  1. Best Answer

    见https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Contents_of_inode.i_block

    “文件标志：524288”是十六进制的 0x80000，所以它是“范围”标志。因此，尽管您extundelete将该块解释inode.i为直接/间接/双重间接/三重间接块指针，但这是不正确的。但我们仍然可以自己解码。

    “直接块”字段中的第一个数字是 62218，即十六进制的 0xF30A - 扩展树模式 ( eh_magic) 的幻数，确认“文件标志”值。由于旧式块指针是 little-endian 32 位，但扩展模式幻数是 16 位，我们知道该eh_entries字段将作为第一个“直接块”编号的一部分显示。既然没有弄乱显示的幻数，eh_entries就一定是零。

    同样，“直接块”中的第二个数字是 4，它解码为两个 16 位数字：4 表示eh_max，0 表示eh_depth。该inode.i块的其余部分似乎全为零。

    所以这里是inode.i根据extent模式解释的块的内容：

    • eh_magic= 62218，正确。
    • eh_entries= 0，标头后面没有有效条目。
    • eh_max= 4，最多 4 个条目inode.i。
    • eh_depth= 0，这个extent节点会直接指向数据块
    • eh_generation= 0（不被标准使用ext4）

    其余的inode.i都是零，所以这里没有有效的struct ext4_extentnorstruct ext4_extent_idx节点，确认eh_entries值为0。

    所以不幸的是，作为删除操作的一部分，extent table 似乎已经被清零，并且指示文件块在磁盘上的位置的实际指针已经消失。所以你是对的，这确实只是一个存根。

    • 2

相关问题