因断电导致整个存储瘫痪，数据成功恢复案例

一、故障描述

由于机房突然断电导致整个存储瘫痪，在来电之后存储依然无法使用。经过用户方工程师诊断后认为断电导致存储阵列损坏。阵列是由12块日立硬盘（3T SAS硬盘）组成的RAID 6。整个存储被分成一个卷，分配给几台VMware的ESXI主机做共享存储。整个卷中存放了大量的Windows虚拟机，虚拟机基本都是模板创建的，因此系统盘都统一为160G，而数据盘则为不定大小，数据盘都是精简模式。现需要紧急恢复这些虚拟机。

二、备份数据

将故障存储的所有磁盘和备份数据的目标磁盘盘连入到一台Windows server 2008的服务器上。故障磁盘都设为脱机（只读）状态，在专业工具Winhex下看到的连接状态。如下：(图中HD1-HD12为目标备份磁盘，HD13-HD24为源故障磁盘，型号为HUS723030ALS640)：

使用Winhex 对HD13-HD24以底层方式读取扇区，发现大量坏扇区。初步判断可能是这种硬盘的读取机制与常见的硬盘不太一样，尝试更换操作主机、更换HBA卡、更换扩展柜、更换操作系统为LINUX，均呈现相同故障。与NETAPP的工程师联系，未得到控制器对磁盘有特别限制。

使用专业工具对硬盘坏扇区分布规则进行检测发现如下规则：

1、坏扇区分布以256扇区为单位

2、除去坏扇区片断的起始位置不固定外，后面的坏扇区间隔都是以2816扇区为间隔。

临时写了个小程序，对每个磁盘的坏扇区绕过处理。用此程序镜像完所有盘的数据。

三、故障分析

1、分析坏扇区

仔细分析坏扇区发现，坏扇区是呈规律性出现。

1、每段坏扇区区域大小总为256个。

2、坏扇区分布为固定区域，每跳过11个256扇区为一个坏的256扇区。

3、坏扇区的位置一直存在于RAID的P校验或Q校验区域。

4、所有硬盘中只有十号盘中有一个自然坏道。

2、分析分区大小

对HD13、HD23、HD24的0-2扇区做分析，可知分区大小为52735352798扇区，此大小按RAID6的模式计算，除以9，等于5859483644扇区，与物理硬盘大小1049524，与DS800控制器中保留的RAID信息区域大小吻合；同时根据物理硬盘底层表现，分区表大小为512字节，后面无8字节校验，大量的0扇区也无8字节校验。故可知，原存储并未启用520字节扇区。

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

四、重组RAID

1、分析RAID结构

存储使用的是标准的RAID 6，因此只需要分析出RAID 成员数量以及RAID的走向就可以重组RAID。

1、分析RAID条带大小

整个存储被分成一个大的卷，分配给几台ESXI做共享存储，因此卷的文件系统肯定是VMFS文件系统。而VMFS卷中又有存放了大量的Windows 虚拟机。Windows虚拟机中大多使用的都是NTFS文件系统，因此可以根据NTFS中的MFT的顺序分析出RAID条带的大小以及RAID的走向。

2、分析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 的MD 1200加上11块3T的硬盘组成一个RAID阵列。接着将重组的RAID数据镜像到目标阵列上。然后利用专业的工具UFS解析整个VMFS文件系统。

2、尝试挂载恢复的VMFS卷

将恢复好的VMFS卷连接到我们的虚拟化环境中的一台ESXI5.5主机上，尝试将其挂载到的ESXI5.5的环境中。但是，不知是版本（客户的ESXI主机是5.0版本）原因还是VMFS本身有损坏导致其挂载不成功。尝试使用ESXI的命令挂载也不成功，于是放弃挂载VMFS卷。

七、移交数据

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

1、将MD 1200阵列上的数据通过HBA卡连接到用户的VCenter服务器上。

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

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

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

5、接着将上传完的虚拟机添加到清单，开机验证即可。

6、如果有虚拟机开机有问题，则尝试使用命令行模式修复。或者重建虚拟机将恢复的虚拟机磁盘（既VMDK文件）拷贝过去即可。

7、由于部分虚拟机的数据盘很大，而数据很少。像这种情况就直接导出数据，然后新建一个虚拟磁盘，将导出的数据拷贝至新建的虚拟磁盘中即可。

统计了一下整个存储中虚拟机的数量，大约有200台虚拟机。目前的情况只能通过上述方式将恢复的虚拟机一台一台的恢复到用户的ESXI中。由于是通过网络传输，因此整个迁移的过程中网络是一个瓶颈。经过不断的调试以及更换主机最终还是无法达到一个理想的状态，最终决定还是以目前的环境迁移吧！不能耽误整个进度。

八、数据恢复总结

1、故障总结

经过仔细分析后得出坏道的结论如下：

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

2、坏道区域表现多数表现为完整的256个扇区，正好当时创建RAID6时的一个完整RAID块大小。

3、活动区域表现为坏道，非活动区域坏道有可能不出现，如热备盘，令上线不足10%，坏道数量就比其他在线盘少（热备盘的镜像4小时即完成，其他有坏道盘大概花费40小时，预估坏道少90%左右）

4、其他非Q校验区域完好，无任何故障。

结论：

通常情况，经如上坏道规则表现可推断：

    坏道为控制器生成Q校验，向硬盘下达IO指令时，可能表现为非标指令，硬盘内部处理异常，导致出现规律性坏道。

2、数据恢复总结

整个数据恢复的过程由于坏道数量太多，导致备份数据花费了很长世间。整个存储是因为坏道引起的，所以最终恢复的数据还是有部分破坏，但整体比例还是很理想的，最终的结果也为可接受范围。

整个恢复的过程因用户比较紧急，我司也安排工程师加班加点在最短的时间内将数据恢复出来。在后续的数据迁移过程中也是由我工程师和用户方工程师配合完成的。