☰

通过不再存在于日志中的索引节点进行恢复？

tag-icon • tag-icon data-recovery inode extundelete
通过不再存在于日志中的索引节点进行恢复？

我从 Windows 计算机的 SMB 共享中删除了一个文件夹。由于零确认，整个文件夹被删除。第一次跑摄影提取了除最后一个复制文件 1 之外的大部分文件。进一步测试扩展删除能够拉出整个文件夹减去 4-5 个文件。然而，最重要的一个文件又没有被恢复。查看索引节点，我可以看到恢复的文件具有连续的索引节点。所以我能够缩小确切的索引节点范围。但是我得到以下尝试恢复该特定索引节点的信息。

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

使用调试文件我试图转储索引节点，但我得到的只是一个大小正确但为零的文件。

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

答案1

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

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

“直接块”字段中的第一个数字是 62218，即十六进制的 0xF30A - 范围树模式 ( eh_magic) 的幻数，确认“文件标志”值。由于旧式块指针是小尾数 32 位，但范围模式幻数是 16 位，因此我们知道该eh_entries字段将显示为第一个“直接块”数字的一部分。由于它没有弄乱显示的幻数，因此eh_entries必须为零。

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

inode.i下面是根据范围模式解释的块的内容：

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

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

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

相关内容