机房断电存储瘫痪恢复案例
机房突然断电导致整个存储瘫痪，加电后存储依然无法使用。经过用户方工程师诊断认为是断电导致存储阵列损坏。整个存储是由12块日立硬盘（3T SAS硬盘）组成的RAID-6磁盘阵列，被分成一个卷，分配给几台Vmware的ESXI主机做共享存储。
整个卷中存放了大量的Windows虚拟机，虚拟机基本都是模板创建的，因此系统盘都统一为160G。数据盘大小不确定，并且数据盘都是精简模式。
故障情况检测
考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一操作不当导致数据无法再次恢复。使用WinHex 以底层方式读取扇区，发现了大量损坏扇区。
初步判断可能是这种硬盘的读取机制与常见的硬盘不一样。尝试更换操作主机，更换HBA卡，更换扩展柜，更换为Linux操作系统，均呈现相同故障。与用户方工程师联系，对方回应此控制器对磁盘没有特殊要求。使用专业工具对硬盘损坏扇区的分布规律进行检测，发现如下规则：
1、损坏扇区分布以256个扇区为单位。
2、除损坏扇区片断的起始位置不固定外，后面的损坏扇区都是以2816个扇区为间隔。所有磁盘的损坏扇区分布如下表（只列出前3个损坏扇区）：
临时写了个小程序，对每个磁盘的损坏扇区做绕过处理。用此程序镜像完所有盘的数据。
故障情况分析
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)：
数据恢复过程
1、分析RAID结构
存储使用的是标准的RAID-6阵列，接下来只需要分析出RAID 成员数量以及RAID的走向就可以重组RAID。
2、分析RAID条带大小
整个存储被分成一个大的卷，分配给几台ESXI做共享存储，因此卷的文件系统肯定是VMFS文件系统。而VMFS卷中又有存放了大量的Windows 虚拟机。Windows虚拟机中大多使用的是NTFS文件系统，因此可以根据NTFS中的MFT的顺序分析出RAID条带的大小以及RAID的走向。
3、分析RAID是否存在掉线盘
镜像完所有磁盘。后发现最后一块硬盘中并没有像其他硬盘一样有大量的坏道。其中有大量未损坏扇区，这些未损坏扇区大多是全0扇区。因此可以判断这块硬盘是热备盘。
4、重组RAID
根据分析出来的RAID结构重组RAID，能看到目录结构。但是不确定是否为最新状态，检测几个虚拟机发现有部分虚拟机正常，但也有很多虚拟机数据异常。初步判断RAID中存在掉线的磁盘，依次将RAID中的每一块磁盘踢掉，然后查看刚才数据异常的地方，未果。又仔细分析底层数据发现问题不是出在RAID层面，而是出在VMFS文件系统上。VMFS文件系统如果大于16TB的话会存在一些其他的记录信息，因此在组建RAID的时候需要跳过这些记录信息。再次重组RAID，查看以前数据异常的地方可以对上了。针对其中的一台虚拟机做验证，将所有磁盘加入RIAD中后，这台虚拟机是可以启动的，但缺盘的情况下启动有问题。因此判断整个RAID处在不缺盘的状态为最佳。
数据验证及结果
1、验证虚拟机
针对用户较为重要的虚拟机做验证，发现虚拟机大多都可以开机，可以进入登陆界面。有部分虚拟机开机蓝屏或开机检测磁盘，但是光盘修复之后都可以启动。
2、验证数据库
针对重要的虚拟机中的数据库做验证，发现数据库都正常。其中有一个数据库，据用户描述是缺少部分数据，但是经过仔细核对后发现这些数据在数据库中本来就不存在。
3、检测整个VMFS卷是否完整
由于虚拟机的数量很多，每台都验证的话，所需的时间会很长，因此我们对整个VMFS卷做检测。在检测VMFS卷的过程中发现有部分虚拟机或虚拟机的文件被破坏。列表如下：
FROMBYTE
由于时间紧迫，先安排北亚工程师将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中。由于是通过网络传输，因此整个迁移的过程中网络是一个瓶颈。经过不断的调试以及更换主机最终还是无法达到一个理想的状态，由于时间紧张，最终还是决定在当前的环境迁移数据。所有磁盘坏道的规律如下表：经过仔细分析后得出坏道的结论如下：
除去SN：YHJ6LEUD上的一个自然坏道外，其余坏道均分布于RAID-6的Q校验块中；坏道区域多数表现为完整的256个扇区，正好当时创建RAID-6时的一个完整RAID块大小；活动区域表现为坏道，非活动区域坏道有可能不出现，如热备盘，上线不足10%，坏道数量就比其他在线盘少（热备盘的镜像4小时完成，其他有坏道盘大概花费40小时）；其他非Q校验区域完好，无任何故障。
通常情况，经如上坏道规则表现可推断，坏道为控制器生成Q校验，向硬盘下达IO指令时，可能表现为非标指令，硬盘内部处理异常，导致出现规律性坏道。整个存储是由坏道引起的，导致最终恢复的数据有部分破坏，但不影响整体数据，最终的结果也在可接受范围内，本次数据恢复成功。
END
往期推荐
北亚数据恢复中心主要从事服务器数据恢复、
磁盘阵列数据恢复（DEll、HP、IBM、华为、NetApp等），
虚拟化数据恢复（VSAN、VMware、Kvm等），
数据库数据恢复（Oracle、Sql Server、MySql、Mongodb等），
小型机数据恢复等方面的数据恢复服务。
扫码关注我们
更多精彩内容等着您
24小时数据救援电话：4006-505-646
地址：北京市海淀区中关村创客小镇16号221室
