服务器数据恢复—fsck修复导致ext4文件系统文件丢失的数据恢复案例

服务器数据恢复环境：
某品牌服务器+同品牌存储，Linux centos7+EXT4文件系统。

服务器故障：
意外断电导致服务器操作系统不能正常启动。经过修复后系统可以正常启动，但是挂载的分区无法正常访问。使用fsck修复这个问题分区，虽然修复完成之后文件系统正常，但是发现部分文件丢失，查看后发现缺失的部分文件在lost+found文件夹里，文件名已经发生改变。

服务器数据恢复过程：
1、将存储上的出现问题的lun以只读模式映射到一台windows server系统服务器上，以扇区的方式镜像到备份空间，后续的数据分析和数据恢复操作均在备份的数据上进行，避免对原始数据造成二次破坏。
2、基于镜像数据分析故障卷的底层数据，发现服务器异常断电导致虚拟机目录下的目录项被破坏。这种破坏不会影响重要数据，只是破坏了文件的目录项，可以通过人工修复解决。之后工作人员使用fsck修复文件系统，导致文件目录结构丢失。损坏的目录项修复不成功，直接以目录节点号命名放到lost+found文件夹下。这时，目录项对应的数据区索引会被清掉，但是也不会影响删除文件的实际数据。可以根据删除虚拟磁盘文件中的文件系统以及虚拟磁盘中的文件类型，在VMFS卷自由空间中进行碎片匹配和合并，恢复删除的虚拟磁盘文件。
由于ext4文件系统文件丢失后，文件的节点信息也会被清除，所以无法根据文件的节点信息恢复数据，只能将丢失的文件的目录项节点号和lost+found里面的文件的名称进行匹配。由于lost+found里面的文件是以文件的目录项的节点号命名的，所以把目录项节点号提取出来和lost+found里面的文件名进行匹配就可以还原之前的目录结构。
3、按照上述思路分析底层数据。根据EXT4的文件系统结构信息，在底层的空间中扫描符合的目录项的区域，统计其数量和计算目录项的节点号。根据磁盘中的文件系统的信息，北亚企安数据恢复工程师将这些扫描到的目录项节点号进行整合，将扫描到的目录项节点号记录到数据库。将lost+found里面的文件记录号和数据库里面的记录号进行匹配。
4、经过匹配，数据正常恢复。经过数据恢复工程师和用户方的验证都没有发现问题，数据恢复工作完成。