1.故障发生背景
Ext4文件系统没有umount下来，之后做了fsck操作检查一致性，结果导致Ext4文件mount不上，并且导致目录变成了文件。
报错提示信息：mount: wrong fs type, bad option, bad superblock
2.故障原理分析
某故障时，日志和数据不一致造成的正常文件系统数据被覆盖的现象。这种故障在Ext3、Ext4文件系统常有发生，好在.journal日志文件留有缓冲，恢复时可以从.journal日志文件里找到相应信息，并粘贴回相应位置，达到重建原文件的目的。
3.案例重要信息
Linux系统的硬盘的第一个扇区是MBR扇区，从MBR分区表能看出来，本案例一共有两个分区。第一个分区是交换分区，共7.8G，第二个分区是Ext4文件系统，共292G。总的大小为300G。
Ext3、Ext4文件系统有日志功能，本案例可以从.journal日志文件中找到丢失数据。
1. 块大小为4KB，即8个扇区。
2. 超级块(Superblock)起始位置在1024字节处，即2号扇区，大小为2个扇区。
3. 块组描述表从第一个块开始，即从4096字节处开始。
4.案例重要概念
超级块(Superblock)：用于存储文件系统的配置参数(如块大小、总块数、i-节点数)和动态信息(当前空闲块数和i-节点数)。Ext4文件系统的超级块(Superblock)开始于1024字节处，即2号扇区。
块组：Ext4文件系统的全部空间被划分为若干个块组，每个块组内的结构都是大致相同的。
块组描述符表：每个块组都对应一个块组描述符，这些块组描述符统一放在文件系统的前部，称为块组描述符表。每个块组描述符大小为32字节，其主要描述块位图、i-节点位图及i-节点表的地址等信息。
i节点：描述文件的时间信息、大小、块指针等信息。
块组描述符和超级块在块中的位置：当块大小为2个扇区时，0号块是引导程序或者保留块，超级块起始于1号块。当块大小为4个扇区时，引导程序或者保留块位于0号块的前两个扇区，超级块位于0号块的后两个扇区。当块大小为8个扇区时，引导程序或者保留块位于0号块的0-1号扇区，超级块位于0号块的2-3号扇区。
Ext4文件系统的整体结构及第一个块组的具体结构如图1所示。
5.解决步骤
步骤总结：
1.通过.journal日志文件里的超级块备份找到超级块，确定块大小。
2.通过.journal日志文件里的超级块备份找到超级块，重建超级块信息。
3.通过.journal日志文件找到目录节点，重建(恢复)目录。
4.通过.journal日志文件找到目录节点找到要恢复的文件的节点信息，重建(恢复)文件。
首先用WinHex打开Ext4文件系统，可以看到0-23扇区的数据(包括超级块和块组描述符)被日志记录覆盖。Ext3、Ext4文件系统的日志页以C0 3B 39 98开头。如图2所示。
图2
1.确定块大小
超级块中有关于块大小的信息。从.journal日志中查找超级块的备份。用WinHex查找得到.journal日志中超级块的信息，其标志是“53ef”。查找超级块方式如图3所示。查看块大小方法如图4和图5所示。超级块0x18-0x1B处描述块大小，确定本案例块大小为4KB。
图3
通过超级块查看块大小如图4所示。
图4
或者WinHex模板编辑器也可以显示块大小如图5所示。
图5
2. 重建(恢复)超级块
由于原文件系统超级块损坏，所以恢复文件时，要把这部分超级块信息粘贴回去，即放在2号扇区开始，或1024字节处。
做完以上操作，超级块备份某些地方与实际的超级块数值可能不一致，需要通过WinHex的模板管理器修改一下。本案例对超级块所在的块组作了修改，它在第0个块组里。如图6所示。
图6
3. 重建(恢复)块组描述表
由于部分块组描述表被破坏，所以在.journal日志文件里找到所有的块组描述表，并把它们粘贴回去。