Linux ext4 rm 数据恢复原理（一）-文件系统结构及文件解析

注意

本文仅理论探讨，真实数据恢复，敬请先参考：

《Linux ext4 rm 误删，用extundelete恢复失败/报错，无数血泪教训！！！附：ext4误删后的正确处理步骤》

Linux ext4 rm 误删，用extundelete恢复失败/报错，无数血泪教训！！！附：ext4误删后的正确处理步骤_DATAUNIT.CN的博客-CSDN博客_extundelete恢复出错

基本概念

1扇区（sector）=512字节(byte)

1数据块(block)=8扇区=4KB(mkfs时指定，默认4KB，可设置为1KB - 64KB)

Ext4字段使用little-endian顺序写入磁盘；但journal日志使用big-endian顺序写入磁盘。

ext4文件系统结构

块设备被划分为多个group
Super block在Group 0中, backup super block存放在其它group的头部

SuperBlock

superblock记录文件系统的各种信息，例如block总数，inode总数，支持的功能，维护信息等。如果sparse_super置位，则superblock和组描述符的副本仅保留在Group编号为0或3、5、7……的Group中。如果未设置该标志，superblock在所有组中均有副本。

Magic signature=0x53EF，位于偏移0x38，即56字节处。UUID位于偏移0x68：

块组描述段

即Block Group Descriptor，描述本group的inode信息、datablock信息

当block=1kb时，BGD起始于block2

当block>1kb时，BGD起始于block1

本案例中为block=1kb，则BGD起始了block2

Inodetable位于BGD偏移0x8处，：

inode table

Inode字段定义：

如果文件<=12个block，inode中可以直接存储其所有block指针。

如果文件的block数据在13个block 至【 ($block_size / 4) ^ 3 + ($block_size / 4) ^ 2 + ($block_size / 4) + 12】个block之间，则需要借助多级索引来存储所有数据块。本案例block=1kb，三线索引inode可存储16777216+65536+268=16843020byte，大概16MB文件。

inode中有15个指针数组，其中12个是直接索引，后面三个分别是一级索引、二级索引和三级索引。如下图示：

如果文件大于16MB，则需要inode开启扩展属性i_extra_isize，使用Extent Tree，本文不再展开。

Group0的inode table处数值为0x0124，即block292，即 292*2=584扇区：

datablock

如上图，文件Inode为14

定位Group：(14-1)/2032=0，位于Group0。（注：此例中，每Group包含2032个inode）
定位Group-inode：(14-1)% 2032=13，位于第13个inode

Group0 inode table起始于block 292，

而inode14位于（14-1）*128=1664 byte = 0x680 byte .

Inode偏移60byte=0x3C byte处，记录了文件的数据块索引，下图为0x000029b7：

第0x000029b7=10679个数据块，位于：10679*1024byte/512byte=21358扇区，下图显示为文件的真实内容：

Ext4引入 “Extents”概念，可参考《Linux ext4文件系统原理（二）-大文件Extent结构解析及数据恢复实例-rm误删恢复》

技术支持

温馨提示：如重要数据丢失，还请在行动前咨询专业工程师建议，以免数据遭到二次破坏。

直接技术支持：shop396558956.taobao.com

官方网站：http://www.dataunit.cn/