Ext4文件系统fsck后损坏的修复过程-linux数据恢复

在数据恢复案例开始之前有几个概念需要了解
块组：Ext4文件系统的全部空间被划分为若干个块组，每个块组内的结构都是大致相同的。
块组描述符表：每个块组都对应一个块组描述符，这些块组描述符统一放在文件系统的前部，称为块组描述符表。每个块组描述符大小为32字节，其主要描述块位图、i-节点位图及i-节点表的地址等信息。
超级块(Superblock)：用于存储文件系统的配置参数(如块大小、总块数、i-节点数)和动态信息(当前空闲块数和i-节点数)。Ext4文件系统的超级块(Superblock)开始于1024字节处，即2号扇区。
i节点：描述文件的时间信息、大小、块指针等信息。
块组描述符和超级块在块中的位置：当块大小为2个扇区时，0号块是引导程序或者保留块，超级块起始于1号块。当块大小为4个扇区时，引导程序或者保留块位于0号块的前两个扇区，超级块位于0号块的后两个扇区。当块大小为8个扇区时，引导程序或者保留块位于0号块的0-1号扇区，超级块位于0号块的2-3号扇区。
Ext4文件系统的整体结构及第一个块组的具体结构
如图1所示。

数据恢复初检和分析：
某公司Ext4文件系统umount失败，管理员进行了fsck操作检查一致性，结果导致Ext4文件mount不上(有时也会表现为导致目录变成了文件)。报错提示信息：mount: wrong fs type, bad option,bad superblock
由于日志和数据不一致造成正常文件系统数据被覆盖的情形在Ext3、Ext4文件系统中发生频率较高，不过journal日志文件留有缓冲数据，数据恢复时可以通过joumal日志文件找到相应信息并重建源文件。

Linux系统的硬盘的第一个扇区是MBR扇区，通过MBR分区表观察得知本案例中共分为两个分区，分别为大小为7.8G的交换分区和大小为282G的文件系统，共300G文件大小。数据恢复工程师探讨后决定通过joumal日志文件分析找回丢失的数据。

1.块大小为固定的4KB，即8个扇区。
2. 超级块(Superblock)起始位置在1024字节处，即2号扇区，大小为2个扇区。

3.块组描述表从第一个块开始，即从4096字节处开始。

数据恢复过程

首先用数据恢复工具将Ext4文件系统打开，可以看到0-23扇区的数据(包括超级块和块组描述符)被日志记录覆盖。Ext3、Ext4文件系统的日志页以C0 3B 39 98开头。如图2所示。

超级块中可以反映出关于块大小的信息。从.journal日志中吧超级块的备份查找出来再通过数据恢复工具进行超级块信息的查找。其标志是“53ef”。查找超级块方式如图3所示。查看块大小方法如图4和图5所示。超级块0x18-0x1B处描述块大小，确定本案例块大小为4KB。

通过超级块查看块大小如图4所示。

图4

通过数据恢复软件的模板编辑器也可以显示块大小如图5所示。

图5
第二步，重建(恢复)超级块；由于原文件系统超级块损坏，所以恢复文件时，要把这部分超级块信息粘贴回去，即放在2号扇区开始，或1024字节处。做完以上操作，超级块备份某些地方与实际的超级块数值可能不一致，需要通过数据恢复工具的模板管理器进行修改。本案例对超级块所在的块组作了修改，它在第0个块组里。
如图6所示。

图6

第三步：重建(恢复)块组描述表；由于部分块组描述表被破坏，所以在.journal日志文件里找到所有的块组描述表，并把它们粘贴回去。.journal日志文件里，如图1所示，块组描述符表存储在超级块的后面。所以要找块组描述表时，可以先找到超级块。找到后将块组描述符表内容粘贴到4096字节处。

第四步；重建(恢复)目录；当我们要恢复某个文件夹里的文件时，比如我们需要恢复kyproc文件夹里的数据。我们发现这些文件夹在WinHex里是不能打开的状态。如图7所示。很明显这个目录损坏了，打开其节点信息，发现正常数据被日志填充，如图8所示。

图7

图8
我们找到它的上一级目录，即var文件夹。右击点“open”，打开看到var文件里的所有文件的目录信息。找到要恢复的kyproc目录的信息，12 32 EE 00是其i-节点号，10 00表示其目录项长度，06表示其文件名称长度，02表示其文件类型为目录。如图9所示。

图9
然后在var文件夹的目录块下查找kyproc目录的位置，如图10所示，标红的位置是找到的结果。此位置显示所在块号为62399108。

图10
根据所在块号，就可以定位kyproc目录相应节点的位置。由于人工补节点比较繁琐，我们可以打开.journal日志文件，从里面找到其节点信息，把相应的信息粘贴回去。
上述方法可以重建(恢复)目录，恢复目录里的文件也是通过同样的方法从.journal日志文件里找到相应的文件的节点信息，找到后粘贴回原来的位置，达到重建(恢复)文件的目的。

Ext4文件系统fsck后损坏的修复过程-linux数据恢复相关推荐

linux ext4文件系统超级块损坏修复
前言误操作 dd if=/var/www/html/admin.php of=/dev/sdb 之后系统报磁盘空间不足,意识到出事了解决 debugfs -w /dev/sdb 返回,/dev/s ...
mysql ext3 ext4_给你一个惊喜：EXT3/EXT4文件系统数据删除后的数据恢复
所谓的日志型文件系统,就是文件系统中做了什么操作,操作系统就把它记录下来,比如创建一个新文件,操作系统会在日志文件中记录下来, 删除一个文件,操作系统也会在日志文件中记录下来,记录的信息包括文件名称. ...
linux文件系统pdf_一篇文章理解Ext4文件系统的目录
使用过Linux的同学应该对Ext4文件系统都有了解.在Linux文件系统中一切皆文件,同样目录也是文件的一种类型.熟悉Linux服务器的同学经常会看到如下内容,上图是某个目录的列表内容. 在上图中每 ...
linux系统fsck.ext4,linux – 如何在fsck之后恢复损坏的ext4文件系统？
我在软件raid5上有一个ext4文件系统.当我开始耗尽空间时,文件系统运行"好了"好几年了.我在6x2T硬盘上有9T的音量.我开始通过执行mdadm失败,删除,添加,重建,重复过 ...
Linux文件系统中错误的是,linux – ext4文件系统损坏 – 可能是硬件错误？
我打开电脑约半小时后,我在dmesg中收到这些错误: [ 1355.677957] EXT4-fs error (device sda2): htree_dirblock_to_tree: inode ...
linux重新识别逻辑卷,linux – 从已删除的LVM逻辑卷恢复ext4文件系统的任何方法？...
前几天,当我在Vmware下的 Linux客户端上扩展磁盘时,我有一个适当的大脑放屁时刻.我将Vmware磁盘文件扩展到所需的大小然后我做了我通常在没有LVM的Linux客户端上做的事情:我删除了LV ...
android ext4 损坏,EXT4文件系统损坏导致的实例无法启动的排查与修复
现象某现网局点进行POC时,发现某DN core掉,且一直无法启动. core文件堆栈和dn的pg_log日志中的堆栈信息一致. 堆栈中显示 checkpoint 时进行 buffer 落盘时导致c ...
Linux ext4文件系统inode信息修改
引文(引用博客:https://blog.csdn.net/stringnewname/article/details/73740155):Linux访问文件过程 1.当我们输入cat testfil ...
[ Linux驱动炼成记 ] 15 - 存储器EMMC中Ext4文件系统中磁盘空间占用率100%
产品现象 : 设备(Linux 系统) 运行一段时间后,其中某一个分区 /et/config 突然占用率为100%,而实际空间可能1%都不到. 这种问题百思不得其解.谷歌/百度所遇到的解决方案都是嵌 ...

Ext4文件系统fsck后损坏的修复过程-linux数据恢复

Ext4文件系统fsck后损坏的修复过程-linux数据恢复相关推荐

最新文章

热门文章