1、二、备份数据将故障存储的所有磁盘和备份数据的目标磁盘连入到一台Windows Server 2008的服务器上。故障磁盘都设为脱机（只读）状态，在专业工具WinHex下看到连接状态如下图所示：(图中HD1-HD12为目标备份磁盘，HD13-HD24为源故障磁盘，型号为HUS723030ALS640)：
3、三、故障分析1、分析损坏扇区仔细分析损坏扇区发现，损坏扇区呈规律性出现。1、每段损坏扇区区域大小总为256。2、损坏扇区分布为固定区域，每跳过11个256扇区遇到一个坏的256扇区。3、损坏扇区的位置一直存在于RAID的P校验或Q校验区域。4、所有硬盘中只有10号盘中有一个自然坏道。
4、分析分区大小对HD13、HD23、HD24的0-2扇区做分析，可知分区大小为52735352798扇区，此大小按RAID-6的模式计算，除以9，等于5859483644扇区，与物理硬盘大小1049524，和DS800控制器中保留的RAID信息区域大小吻合；同时根据物理硬盘底层表现，分区表大小为512字节，后面无8字节校验，大量的0扇区也无8字节校验。故可知，原存储并未启用存储中常用的DA技术(520字节扇区）。分区大小如下图(GPT分区表项底层表现，涂色部分表示分区大小，单位512字节扇区，64bit)：
8、验证数据库针对重要的虚拟机中的数据库做验证，发现数据库都正常。其中有一个数据库，据用户描述是缺少部分数据，但是经过仔细核对后发现这些数据在数据库中本来就不存在。通过查询 master 数据库中的系统视图，查出原来的所有数据库信息如下：
10、六、恢复数据1、生成数据北亚皤材装肢工程师跟客户沟通并且描述了目前恢复的情况。用户经过对几台重要的虚拟机验证后，用户反应恢复的数据可以接受，接着北亚工程师立即着手准备恢复所有数据。囗寝嗵若先准备目标磁盘，使用一台dell 的MD 1200加上11块3T的硬盘组成一个RAID阵列。接着将重组的RAID数据镜像到目标阵列上。然后利用专业的工具UFS解析整个VMFS文件系统。2、尝试挂载恢复的VMFS卷将恢复好的VMFS卷连接到我们的虚拟化环境中的一台ESXI5.5主机上，尝试将其挂载到的ESXI5.5的环境中。但是由于版本（客户的ESXI主机是5.0版本）原因或VMFS本身有损坏，导致其挂载不成功。继续尝试使用ESXI的命令挂载也不成功，于是放弃挂载VMFS卷。
11、七、移交墙绅褡孛数据由于时间紧迫，先安排北亚工程师将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中。由于是通过网络传输，因此整个迁移的过程中网络是一个瓶颈。经过不断的调试以及更换主机最终还是无法达到一个理想的状态，由于时间紧张，最终还是决定在当前的环境迁移数据。
12、八、数据恢复总结经过仔细分析后得出坏道的结论如下：1、除去SN：YHJ6LEUD上的一个自然坏道外，其余坏道均分布于RAID-6的Q校验块中。2、坏道区域多数表现为完整的256个扇区，正好当时创建RAID-6时的一个完整RAID块大小。3、活动区域表现为坏道，非活动区域坏道有可能不出现，如热备盘，上线不足10%，坏道数量就比其他在线盘少（热备盘的镜像4小时完成，其他有坏道盘大概花费40小时）4、其他非Q校验区域完好，无任何故障。结论：通常情况，经如上坏道规则表现可推断，坏道为控制器生成Q校验，向硬盘下达IO指令时，可能表现为非标指令，硬盘内部处理异常，导致出现规律性坏道。
13、数据恢复总结数据恢复过程中由于坏道数量太多，以致备份数据时花费了很长世间。整个存储是由坏道引起的，导致最终恢复的数据有部分破坏，但不影响整体数据，最终的结果也在可接受范围内。整个恢复过程，用户方要求紧急，我方也安排工程师加班加点，最终在最短的时间内将数据恢复出来。后续的数据迁移过程中由我方工程师和用户方工程师配合完成。
