一、服务器数据恢复故障描述机房突然停电导致整个存储瘫痪，上电后存储仍然不可用。经用户工程师诊断，认为是存储阵列因停电损坏。整个存储是由12块日立硬盘（3TSAS硬盘）组成的RAID-6磁盘阵列，分成一个卷，分配给多台VmwareESXI主机共享存储。整个卷里面存放了大量的Windows虚拟机，而且虚拟机基本都是模板创建的，所以系统盘统一160G。数据盘大小不确定，数据盘都是压缩模式。2、服务器数据恢复备份数据将故障存储的所有磁盘和备份sss数据的目标磁盘连接到一台WindowsServer2008服务器上。故障盘全部设置为离线（只读）状态，在专业工具WinHex中可以看到连接状态如下图：（图中HD1-HD12为目标备份盘，HD13-HD24是源头故障盘，型号为HUS723030ALS640）：图1：使用WinHex低级读取HD13-HD24扇区，发现大量损坏扇区。初步判断可能是该硬盘的读取机制与普通硬盘不同。尝试更换运行主机，更换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字节校验，大量的分区表也没有8字节校验。0个扇区。测试。因此可以看出，原始存储并没有启用存储常用的DA技术（520字节扇区）。分区大小如下图（GPT分区表项底层性能，彩色部分表示分区大小，单位为512字节扇区，64bit）：图2：4.重组RAID1并分析RAID结构存储采用标准的RAID-6阵列，然后只需要分析RAID成员的数量和RAID的方向即可重组RAID。-RAIDstripesize分析整个存储分成一个大volume，分配给几个ESXI作为共享存储，所以volume的文件系统必须是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、验证虚拟机；验证对用户比较重要的虚拟机，发现大部分虚拟机都可以开机进入登录界面。有些虚拟机启动时出现蓝屏或磁盘检测，但修复光盘后都可以启动。部分虚拟机启动现象如下：图3：2.验证数据库；验证重要虚拟机中的数据库，发现数据库正常。其中一个数据库，根据用户的描述，缺失了一些数据，但仔细检查后发现，这些数据并不存在于数据库中。通过查询master数据库中的系统视图，发现所有原始数据库信息如下：图4：3.查看整个VMFS卷是否完整；由于虚拟机数量较多，每台验证需要很长时间，所以我们检查整个VMFS卷。检测VMFS卷时，发现部分虚拟机或虚拟机文件损坏。清单如下：图5：6.恢复数据1.生成数据；北亚工程师与客户沟通，描述了目前的恢复情况。在用户验证了几台重要的虚拟机后，用户反馈恢复的数据可以接受，随后北亚工程师立即开始准备恢复所有数据。先准备目标盘，用一块dellMD1200加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小时完成，其他盘有坏道）sectors.trackdisk大概用了40个小时)-其他非Qcheckarea都完好无损.结论：总的来说，从上述坏道规则的表现可以推断，坏道是controller产生的Qcheck。当向硬盘下发IO命令时，可能会出现非标准命令，硬盘内部处理不正常，造成常规坏道。2、数据恢复小结：由于数据恢复过程中坏道较多，备份数据时间较长。整个存储都是坏道造成的，导致最终恢复的数据有部分损坏，但不影响整体数据，最终的结果也在可接受的范围内。整个恢复过程中，用户要求紧急，我们也安排工程师加班加点，最终在最短的时间内恢复了数据。后续的数据迁移过程由我们的工程师和用户工程师共同完成。
