Linux服务器数据恢复-服务器修复无法启动错误过程

一、服务器数据恢复故障描述

介绍数据恢复案例前照例先介绍故障服务器的物理状况。本次数据恢复的服务器是linux操作系统，某品牌730系列服务器，MD3200系列存储。导致数据丢失的原因是机房意外断电导致系统无法正常启动，客户管理员对无法访问的服务器进行了修复操作后进入系统查看数据，服务器部分文件已经丢失。于是客户管理员联系了数据恢复中心进行服务器数据恢复。

二、服务器数据恢复故障分析

1.备份客户服务器数据

数据恢复工程师接到客户的服务器后对服务器进行了初检，首先将存储的lun以只读的模式映射到了数据恢复中心的数据恢复专用存储设备上。接着对客户的服务器进行扇区级别的镜像操作，这样做的目的有两个，一个是可以让客户取回原服务器，避免后期的数据恢复过程占用客户设备，另一个是为了保护客户的原有数据，因为数据恢复需要大量的数据分析和尝试，存在有多次尝试的可能，这样在镜像文件中进行数据恢复操作就可以避免在客户的原服务器上进行操作，保护客户原数据的完整性。万一我们恢复失败了，客户也可以携带原服务器到其他公司进行数据恢复操作，是一种对客户数据负责的方式。

2、分析服务器故障原因

备份完成后，服务器数据恢复工程师对底层数据进行查看，发现服务器的目录项已经遭到了破坏，所幸运的是这些目录项的破坏并没影响到服务器的重要数据，仅仅是将目录项破坏了一些，这些破坏可以通过人工进行修复。由于客户的服务器管理员进行过修复操作，这也就导致了损坏的目录项本质上并没有被成功修复，而是以节点号进行命名同时存放到了lost+found文件夹内，对应的数据区索引也被服务器进行了自动清除。工程师以前处理过很多起类似的数据丢失案例，这种情况下只需要根据文件系统和文件类型在自由空间中进行碎片匹配、碎片拼合，最终恢复整个服务器的数据。

linux无法启动数据恢复

三、服务器数据恢复实施过程

在本次数据恢复案例中的节点信息已经被清除，无法根据节点信息还原数据。服务器数据恢复工程师提取出lost+found文件夹下的文件名称，根据丢失文件的文件目录项节点号进行一一匹配，从而分析出丢失的目录结构。再继续分析底层数据，根据文件系统的结构信息在底层空间的相对应位置扫描符合丢失目录结构条件的信息并进行提取，再与目录项节点号进行整合，把扫描到的目录项节点号记录到数据库里面，之后在通过lost+found里面的文件记录号和数据库里面的记录号进行匹配。

四、服务器数据恢复结果

在本次服务器数据恢复案例中，客户的服务器先是异常断电导致文件系统被损坏，接着被管理员进行了人人工修复导致大量文件的目录结构丢失，在修复和检查过程中服务器还写入了一部分的新数据，这就直接导致了本次服务器数据恢复的过程比正常情况下的数据丢失更为复杂一些，由于工程师有着多年的服务器数据恢复经验，在经过一段时间的分析和重组后，最终成功提取出了客户服务器丢失的数据。客户对恢复成功的数据进行验证，经过验证，客户原服务器内的所有数据都恢复成功，可以正常使用，客户认可本次服务器数据恢复结果。