服务器存储瘫痪数据恢复成功案例-服务器数据恢复

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

机房突然断电导致整个存储瘫痪，加电后仍无法使用。经用户工程师诊断，认为是断电导致存储阵列损坏。

整个存储是由12块日立硬盘（3TSAS由硬盘组成RAID-6磁盘阵列，分成一卷，分配给几个Vmware的ESXI主机用于共享存储。整卷中储存了大量Windows虚拟机，虚拟机基本都是模板创建的，所以系统盘都是统一的160G。数据盘大小不确定，数据盘简化。

二、服务器数据恢复备份数据

所有存储故障的磁盘和备份sss数据的目标磁盘连接到一个WindowsServer2008的服务器上。故障磁盘都设为脱机（只读）状态，在专业工具WinHex为目标备份磁盘，HD13-HD24型号为源故障磁盘HUS723030ALS640)：

使用WinHex对HD13-HD24以底层读取风扇区域，发现大量损坏风扇区域。初步判断可能是硬盘的读取机制不同于普通硬盘。尝试更换操作主机和更换HBA卡，更换扩展柜，更换为Linux操作系统，均呈现相同故障。与用户方工程师联系，对方回应此控制器对磁盘没有特殊要求。

使用专业工具检测硬盘损坏风扇区域的分布规则，发现以下规则：

1、损坏的风扇区域分布在256个风扇区域。2.除损坏风扇区域的起始位置不固定外，损坏风扇区域的后部间隔为2816个风扇区域。

所有磁盘损坏的扇区分布如下表所示(只列出前三个损坏的扇区):

临时写一个小程序，绕过每个磁盘损坏的风扇区域。用这个程序镜像所有磁盘的数据。

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

1、分析损坏的风扇区域

仔细分析损坏的风扇区域，发现损坏的风扇区域是有规律的。

-每个损坏的风扇区域总大小为256。-损坏的风扇区域分布在固定区域，每次跳过11个256个风扇区域，遇到256个损坏的风扇区域。-损坏风扇区域的位置一直存在RAID的P校验或Q校验区域。-所有硬盘中只有10号盘中有一个自然坏道。

2、分区大小分析

对HD13、HD23、HD24的0-2分析扇区，可以看出分区大小为52735352798扇区，按此大小RAID-6除以9，等于5859483644扇区，物理硬盘大小1049524，和DS800保留在控制器中RAID信息区大小一致；同时，根据物理硬盘的底部性能，分区表大小为512字节，后面没有8字节验证，大量0个区域没有8字节验证。因此，原始存储在存储中并不常用DA技术(520字节扇区)。

分区大小(GPT分区表项底层表现，涂色部分表示分区大小，单位512字节扇区，64bit)：

四、重组RAID

1、分析RAID结构

存储使用标准RAID-6阵列，接下来只需要分析RAID成员数量和RAID方向可以重组RAID。

-分析RAID条带大小

整个存储被分成一个大分配给几个ESXI做共享存储，所以卷的文件系统一定是VMFS文件系统VMFS卷中储存了大量Windows虚拟机。Windows它主要用于虚拟机NTFS因此，可以根据文件系统NTFS中的MFT顺序分析RAID条带的大小和RAID的走向。

-分析RAID有没有掉线盘？

镜像后所有磁盘。后来发现最后一个硬盘没有其他硬盘那么坏。有大量未损坏的风扇区域，其中大部分为0个风扇区域。因此，可以判断硬盘是热盘。

2、重组RAID

根据分析RAID结构重组RAID，能看到目录结构。但是不确定是否为最新状态，检测几个虚拟机发现有部分虚拟机正常，但也有很多虚拟机数据异常。初步判断RAID有掉线磁盘，依次将RAID每个磁盘都被踢掉，然后检查刚才数据异常的地方，失败了。仔细分析底层数据，发现问题不在RAID层次，但出在VMFS在文件系统上。VMFS如果文件系统大于16TB因此，会有一些其他的记录信息，录信息RAID需要跳过这些记录信息RAID，查看以前数据异常的地方。验证其中一台虚拟机，并添加所有磁盘RIAD中后，这台虚拟机可以启动，但缺盘时启动有问题。所以判断整个RAID最好处于不缺盘的状态。

五、验证数据

1、验证虚拟机；验证用户更重要的虚拟机，发现大多数虚拟机可以启动并进入登录界面。一些虚拟机启动蓝屏或启动检测磁盘，但可以在光盘修复后启动。

2、验证数据库；验证重要虚拟机中的数据库，发现数据库正常。根据用户描述，有一个数据库缺乏部分数据，但经过仔细检查，发现数据库中不存在。通过查询master所有原始数据库信息

3、检测整个VMFS卷是否完整；因为虚拟机的数量很多，如果每台都验证，需要很长时间，所以我们对整个VMFS测试卷VMFS一些虚拟机或虚拟机的文件在滚动过程中被破坏。

六、恢复数据

1、生成数据；微云网络工程师跟客户沟通并且描述了目前恢复的情况。用户经过对几台重要的虚拟机验证后，用户反应恢复的数据可以接受，接着微云网络工程师立即着手准备恢复所有数据。

先准备目标磁盘，用一个dell的MD1200加上11块3T一个硬盘RAID阵列。然后重组RAID数据镜像到目标阵列。然后使用专业工具UFS解析整个VMFS文件系统。

2、试着挂载恢复VMFS卷；会恢复的VMFS卷与我们的虚拟环境相连ESXI5.5试着把它挂在主机上ESXI5.5但是因为版本(客户的ESXI主机是5.0原因或版本VMFS损坏本身，导致挂载失败。继续尝试使用ESXI挂载命令也不成功，所以放弃挂载VMFS卷。

七、移交数据

由于时间紧迫，首先安排微云网络工程师MD1200将阵列上的数据带到用户现场。然后使用专业工具UFS”依次导出VMFS卷中的虚拟机。

1、将MD1200通过阵列上的数据HBA卡与用户相连VCenter服务器上。

2、在VCenter服务器安装服务器安装UFS然后使用工具UFS”工具解释VMFS卷。

3、使用“UFS”工具将VMFS导入卷中的虚拟机VCenter服务器上。

4、使用VCenter虚拟机上传功能ESXI的存储中。

5、然后将上传的虚拟机添加到列表中，启动验证。

6、如果虚拟机启动有问题，请尝试使用命令线模式进行修复。或者重建虚拟机并恢复虚拟机磁盘(既VMDK复制过去的文件)。

7、因为一些虚拟机的数据盘很大，而且数据很少。在这种情况下，您可以直接导出数据，然后创建一个新的虚拟磁盘，最后将导出的数据复制到新的虚拟磁盘中。

据统计，整个存储中大约有200台虚拟机。目前，恢复的虚拟机只能通过上述方式一恢复到用户ESXI中间。由于它是通过网络传输的，网络是整个迁移过程中的瓶颈。经过不断的调试和更换，主机最终无法达到理想的状态。由于时间短，数据最终决定在当前环境中迁移。

八、数据恢复总结

1、故障总结；所有磁盘坏道的规律如下表所示：

经过仔细分析，得出以下结论：

-除去SN：YHJ6LEUD上的一个自然坏道外，其余坏道均分布于RAID-6的Q校验块中。

-大部分坏道区域都是256个完整的扇区，正好是当时创建的RAID-6完整的时间RAID块大小。

-活动区表现为坏道，非活动区可能不会出现坏道。比如热备盘上线不到10%，坏道数量比其他在线盘少(热备盘镜像4小时完成，其他坏道盘40小时左右)

-其他非Q校验区完好，无故障。

结论：

通常，通过上述坏道规则的性能可以推断出坏道是由控制器生成的Q验证，发送到硬盘IO指令时，可能表现为非标准指令，硬盘内部处理异常，导致规律性坏道。

2、数据恢复总结；在数据恢复过程中，备份数据需要很长时间。整个存储是由不良轨道引起的，部分损坏了最终恢复的数据，但不影响整体数据，最终结果也在可接受的范围内。

在整个恢复过程中，用户要求紧急情况。我们还安排工程师加班，最终在最短的时间内恢复数据。在后续的数据迁移过程中，我们的工程师和用户过程中合作完成。