一、故障描述
服务器是dell 730系列服务器，存储阵列是MD3200系列存储5T的Lun，操作系统是Linux centos 7，文件系统类型是EXT4，因意外断电，导致系统不能正常启动，修复之后系统可以正常启动，但是挂载的5T分区不能正常访问了，对这个5T的分区进行fsck修复，修复完成之后文件系统正常，但是丢失了部分文件，仔细查看之后缺失的部分文件在lost+found文件夹里面，文件名称已经被改变。
二、故障分析
1、备份数据
把MD3200存储的5T的lun以只读模式重新映射到一台windows 2008的备份服务器上，接着使用专业的工具将整个5T卷以扇区的方式镜像到已准备的备份空间上，以确保客户的数据安全，之后的分析和恢复操作均在备份的数据上进行。
2、分析故障原因
仔细分析5T卷的底层数据发现，服务器的突然断电导致故障虚拟机目录下的目录项出现破坏，但是这种破坏不会影响重要数据，只是破坏了文件的目录项而已，可以通过人工修复即可解决。而之后对文件系统进行fsck修复，导致损坏的目录项修复不成功，直接以目录节点号命名放到lost+found文件夹下，则目录项对应的数据区索引会被清掉，也不会影响删除文件的实际数据。这种情况可根据删除虚拟磁盘文件中的文件系统以及虚拟磁盘中的文件类型在VMFS卷自由空间中进行碎片匹配和合并，最终也可恢复删除的虚拟磁盘文件。

三、实施方向
由于ext4文件系统文件丢失之后，文件的节点信息被清除了，所以无法根据文件的节点信息进行还原，只能根据丢失的文件的目录项节点号和lost+found里面的文件的名称进行匹配，由于lost+found里面的文件是以该文件的目录项的节点号命名的，所以把目录项节点号提取出来和lost+found的文件名称进行匹配就可以还原之前的目录结构。

四、恢复数据
按照实施方向思路进行底层分析，根据EXT4的文件系统结构信息，在底层的空间中扫描符合的目录项的区域，并统计其数量和计算目录项的节点号。再根据磁盘中的文件系统的信息将这些扫描到的目录项节点号进行整合，把扫描到的目录项节点号记录到数据库里面，之后在通过lost+found里面的文件记录号和数据库里面的记录号进行匹配。

五、恢复总结
由于客户数据先是被突然断电导致文件系统出现问题，接着人为fsck修复导致大量文件目录结构丢失，并且又重新写入部分数据，导致其存在数据覆盖的可能性。由于对ext4文件系统底层结构足够了解，并且有处理过类似故障类型的经验。所以整个恢复过程中还算比较顺利。匹配之后数据正常恢复，并且验证没有问题，整个数据恢复成功。

如何进行服务器Linux系统下的ext文件系统修复