某省云数据中心数据恢复报告

 

1、故障描述

机房忽然断电致使整个存储瘫痪，加电后存储依然没法使用。通过用户方工程师诊断后认为是断电致使存储阵列损坏。整个存储是由12块日立硬盘（3T SAS硬盘）组成的RAID-6磁盘阵列，被分红一个卷，分配给几台Vmware的ESXI主机作共享存储。整个卷中存放了大量的Windows虚拟机，虚拟机基本都是模板建立的，所以系统盘都统一为160G。数据盘大小不肯定，而且数据盘都是精简模式。

 

2、备份数据

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

 

 

 

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

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

一、  损坏扇区分布以256个扇区为单位。

二、  除损坏扇区片段的起始位置不固定外，后面的损坏扇区都是以2816个扇区为间隔。

全部磁盘的损坏扇区分布以下表（只列出前3个损坏扇区）：

ID号	硬盘序列号	第1个损坏扇区	第2个损坏扇区	第3个损坏扇区
13	YHJ7L3DD	5376	8192	11008
14	YHJ6YW9D	2304	5120	7936
15	YHJ7M77D	2048	4864	7680
16	YHJ4M5AD	1792	4608	7424
17	YHJ4MERD	1536	4352	7168
18	YHJ4MH9D	1280	6912	9728
19	YHJ7JYYD	1024	6656	9472
20	YHJ4MHMD	768	6400	9216
21	YHJ7M4YD	512	6144	8960
22	YHJ632UD	256	5888	8704
23	YHJ6LEUD	5632	8448	11264
24	YHHLDLRA	256	5888	8704

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

 

3、故障分析

1、分析损坏扇区

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

一、  每段损坏扇区区域大小总为256。

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

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

四、  全部硬盘中只有10号盘中有一个天然坏道。

 

2、分析分区大小

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

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

4、重组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处在不缺盘的状态为最佳。

5、验证数据

1、验证虚拟机

针对用户较为重要的虚拟机作验证，发现虚拟机大多均可以开机，能够进入登录界面。有部分虚拟机开机蓝屏或开机检测磁盘，可是光盘修复以后均可以启动。

部分虚拟机现象开机以下：

2、验证数据库

针对重要的虚拟机中的数据库作验证，发现数据库都正常。其中有一个数据库，据用户描述是缺乏部分数据，可是通过仔细核对后发现这些数据在数据库中原本就不存在。经过查询 master 数据库中的系统视图，查出原来的全部数据库信息以下：

 

3、检测整个VMFS卷是否完整

因为虚拟机的数量不少，每台都验证的话，所需的时间会很长，所以咱们对整个VMFS卷作检测。在检测VMFS卷的过程当中发现有部分虚拟机或虚拟机的文件被破坏。列表以下：’

 

6、恢复数据

1、生成数据

北亚工程师跟客户沟通而且描述了目前恢复的状况。用户通过对几台重要的虚拟机验证后，用户反应恢复的数据能够接受，接着北亚工程师当即着手准备恢复全部数据。

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

2、尝试挂载恢复的VMFS卷

将恢复好的VMFS卷链接到咱们的虚拟化环境中的一台ESXI5.5主机上，尝试将其挂载到的ESXI5.5的环境中。可是因为版本（客户的ESXI主机是5.0版本）缘由或VMFS自己有损坏，致使其挂载不成功。继续尝试使用ESXI的命令挂载也不成功，因而放弃挂载VMFS卷。

7、移交数据

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

一、  将MD 1200阵列上的数据经过HBA卡链接到用户的VCenter服务器上。

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

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

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

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

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

七、  因为部分虚拟机的数据盘很大，而数据不多。像这种状况就能够直接导出数据，而后新建一个虚拟磁盘，最后将导出的数据拷贝至新建的虚拟磁盘中便可。

 

统计了一下整个存储中虚拟机的数量，大约有200台虚拟机。目前的状况只能经过上述方式将恢复的虚拟机一台一台的恢复到用户的ESXI中。因为是经过网络传输，所以整个迁移的过程当中网络是一个瓶颈。通过不断的调试以及更换主机最终仍是没法达到一个理想的状态，因为时间紧张，最终仍是决定在当前的环境迁移数据。

8、数据恢复总结

1、故障总结

全部磁盘坏道的规律以下表：

 

ID号	硬盘序列号	损坏扇区域（256SEC）分布规则
		位置	备注
13	YHJ7L3DD	5376+N*2816
14	YHJ6YW9D	2304+N*2816
15	YHJ7M77D	2048+N*2816
16	YHJ4M5AD	1792+N*2816
17	YHJ4MERD	1536+N*2816
18	YHJ4MH9D	1280+N*2816
19	YHJ7JYYD	1024+N*2816
20	YHJ4MHMD	768+N*2816
21	YHJ7M4YD	512+N*2816
22	YHJ632UD	256+N*2816
23	YHJ6LEUD	5632+N*2816	98724块区有一天然损坏扇区
24	YHHLDLRA	256+N*2816

 

通过仔细分析后得出坏道的结论以下：

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

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

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

四、  其余非Q校验区域无缺，无任何故障。

 

结论：

一般状况，经如上坏道规则表现可推断，坏道为控制器生成Q校验，向硬盘下达IO指令时，可能表现为非标指令，硬盘内部处理异常，致使出现规律性坏道。

 

2、数据恢复总结

数据恢复过程当中因为坏道数量太多，以至备份数据时花费了很长世间。整个存储是由坏道引发的，致使最终恢复的数据有部分破坏，但不影响总体数据，最终的结果也在可接受范围内。

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

 

9、项目成员 

姓名	职务	电话	EMAIL
张晓娜	商务表明	13161737074
张宇	项目主管	18600440055
邓奇	存储恢复工程师
秦颖吉	虚拟化工程师
张勇	数据库工程师
刘思棋	硬盘工程师
陈琳娜	项目记录

 

 

 

 

 

                         北京北亚时代科技股份有限公司

                                               2014年11月26日