关于数据恢复:服务器数据恢复Linux服务器分区不能挂载的数据恢复案例

27次阅读

共计 1007 个字符,预计需要花费 3 分钟才能阅读完成。

服务器数据恢复环境:
某品牌 PowerEdge 系列服务器,磁盘阵列存储型号为该品牌 MD3200 系列存储,调配 lun;
linux centos 7 操作系统,EXT4 文件系统。

服务器故障:
服务器在工作中因为未知起因忽然关机且无奈启动,管理员通过修复后能够启动服务器,但服务器的某个分区无奈挂载。管理员对无奈挂载的分区执行了 fsck 修复,修复实现后该分区能够胜利挂载,然而查看该分区数据后发现局部文件失落。

服务器数据恢复过程:
1、数据恢复工程师达到现场后将故障服务器以只读模式映射到北亚企安数据恢复服务器上,将所有硬盘数据以只读形式镜像到数据恢复服务器上,后续数据分析和数据恢复操作都基于镜像文件进行,防止对原始数据造成二次毁坏。
2、通过对镜像文件的剖析,数据恢复工程师初步诊断导致该服务器故障的起因是机房供电不稳引起的服务器非正常关机。
3、仔细分析故障服务器的底层数据,发现服务器的异样断电导致目录项被毁坏,所幸的是底层数据仍然存在,只须要数据恢复工程师手工修复即可复原数据。
4、因为管理员对文件系统执行了 fsck 修复,被毁坏的目录项在修复失败后以目录节点号命名,并寄存于 lost+found 目录内,随后又革除了这些目录项所对应的数据区索引。这就是分区挂载胜利后局部文件失落的起因。这样的状况想要复原数据,能够依据被删除的虚构磁盘文件的文件系统和文件类型在 vmfs 卷自由空间中进行排查,匹配碎片并从新合并,最终通过这种形式将删除的虚构磁盘文件复原。
5、因为故障服务器采纳的是 EXT4 文件系统,EXT4 文件系统有一个特点就是文件失落后其节点信息也会被革除,所以在本案例不能采纳基于节点信息进行还原的办法来复原数据,而是依据失落的文件目录项节点号匹配 lost+found 目录下的文件名称这种形式来复原数据。因为 lost+found 目录下的文件命名规定就是该文件的目录项节点号。能够先提取目录项节点号并与 lost+found 目录下的文件名进行一一对应,最终还原出服务器的原始目录构造。
6、基于镜像文件剖析底层,在底层空间扫描目录项的区域,将目录项的节点号、数量等信息进行统计和记录,依据服务器磁盘中的文件系统信息将统计到的目录项和节点号进行整合匹配,而后匹配 lost+found 目录下的文件记录号,最终将服务器分区失落的数据恢复进去。
7、通过管理员对复原进去的数据进行重复验证后,确认复原进去的数据残缺无效,本次数据恢复工作实现。

正文完
 0