服务器存储瘫痪数据恢复成功案例-服务器数据恢复

服务器存储瘫痪数据恢复成功案例-服务器数据恢复

一、服务器数据恢复失败描述

机房突然停电导致整个存储瘫痪，加电后存储无法使用。经用户工程师诊断，认为存储阵列因断电损坏。

整个存储是由12块日立硬盘(3TSAS硬盘)组成的RAID-6磁盘阵列，分成一个卷，分配给多个VmwareESXI主机共享存储。全卷存储了大量的Windows虚拟机，虚拟机基本都是模板创建的，所以系统盘都统一到160G。数据磁盘大小不确定，所有数据磁盘都处于精简模式。

二。服务器数据恢复备份数据

将故障存储的所有磁盘和备份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-check或Q-check区域。-只有第10块硬盘有自然坏道。

2.分析分区大小。

通过分析HD13、HD23、HD24的0-2扇区可以看出，分区大小为52735352798扇区，按照RAID-6模式计算，除以9，等于5859483644扇区，与1049524的物理硬盘大小和DS800控制器中预留的RAID信息区一致。同时根据物理硬盘底层性能，分区表大小为512字节，后面没有8字节校验，大量0扇区也没有8字节校验。所以存储中常用的DA技术(520字节扇区)在原存储中没有启用。

分区大小如下图所示(GPT分区表条目最底层显示，彩色部分显示分区大小，单位为512字节扇区，64bit):

图2:

四。正在重组RAID

1.分析RAID结构。

采用标准的RAID-6阵列进行存储，然后只需要分析RAID成员的数量和RAID的趋势就可以重组RAID。

-分析RAID条带大小

整个存储被划分为一个大卷，并分布到多个ESXI进行共享存储，因此该卷的文件系统必须是VMFS文件系统。此外，大量Windows虚拟机存储在VMFS卷中。Windows虚拟机大多使用NTFS文件系统，所以可以根据NTFS中MFT的顺序来分析RAID条带的大小和RAID的走向。

-分析RAID中是否有丢弃的磁盘。

镜像所有磁盘。发现最后一块硬盘没有其他硬盘坏轨多。有大量未损坏的扇区，大部分都是0。所以可以判断这个硬盘是热备盘。

2.重组突袭

根据分析出来的RAID结构重组RAID，就可以看到目录结构了。但我不确定是不是最新的状态。测试了几个虚拟机，发现有些虚拟机是正常的，但是很多虚拟机有数据异常。初步判断RAID中有掉盘，然后依次踢出RAID中的每个磁盘，然后检查刚才的数据异常，但是失败。仔细分析底层数据后，发现问题不在RAID级别，而在VMFS文件系统。如果VMFS文件系统大于16TB，还会有一些其他记录的信息，所以在构建RAID时需要跳过这些记录的信息。重新整理一遍RAID，检查一下之前数据异常的地方，就可以匹配了。其中一个虚拟机已通过验证。将所有磁盘添加到RIAD后，可以启动这个虚拟机，但是当磁盘丢失时会出现问题。所以最好判断整个RAID处于不缺盘的状态。

验证数据

1.验证虚拟机；验证用户的重要虚拟机，发现大部分虚拟机都可以开启，可以进入登录界面。有些虚拟机有启动蓝屏或启动检测盘，但都可以在光盘修复后启动。一些虚拟机现象按如下方式打开:

图3:

2.验证数据库；验证重要虚拟机中的数据库，发现所有数据库都正常。其中一个数据库，根据用户的描述，缺少了一些数据，但是仔细查了一下，发现数据库中并不存在这些数据。通过查询主数据库中的系统视图，我们可以找到所有原始数据库信息，如下所示:

图4:

3.检查整个VMFS卷是否完整；由于虚拟机数量众多，如果每个都进行验证，将需要很长时间，因此我们测试整个VMFS卷。在检测VMFS卷的过程中，发现部分虚拟机或虚拟机文件损坏。该列表如下:

图5:

六。正在恢复数据

1.生成数据；天下数据工程师与客户沟通，描述了目前的恢复情况。用户验证了几个重要的虚拟机后，用户反应恢复的数据可以接受，然后世界数据工程师马上开始准备恢复所有数据。

首先准备好目标磁盘，用一个dellMD1200和11个3T硬盘组成RAID阵列。然后，重组后的RAID数据会镜像到目标阵列上。然后，使用专业工具UFS对整个VMFS文件系统进行分析。

2.尝试装入恢复的VMFS卷；将恢复的VMFS卷连接到我们虚拟化环境中的ESXI5.5主机，并尝试将其装载到ESXI5.5环境中。但是，由于版本原因(客户的ESXI主机版本为5.0)或VMFS本身损坏，VMFS装载不成功。尝试使用ESXI命令装载VMFS卷失败，因此放弃了VMFS卷。

七。数据移交

由于时间紧迫，我们将安排来自世界各地的数据工程师将MD1200阵列上的数据带到用户现场。然后使用专业工具“UFS”依次导出VMFS卷中的虚拟机。

1.通过HBA卡将MD1200阵列上的数据连接到用户的VCenterserver。

2.在VCenterserver上安装“UFS”工具，然后使用“UFS”工具解释VMFS卷。

3.使用“UFS”工具将VMFS卷中的虚拟机导入VCenterserver。

4.使用VCenter的上传功能将虚拟机上传到ESXI的存储。

5.然后，将上传的虚拟机添加到列表中，并引导它进行验证。

6.如果存在虚拟机启动问题，请尝试使用命令行模式修复它。或者重建虚拟机并复制恢复的虚拟机磁盘(即VMDK文件)。

7.有些虚拟机的数据磁盘非常大，但数据却很少。在这种情况下，您可以直接导出数据，然后创建新的虚拟磁盘，最后将导出的数据复制到新的虚拟磁盘。

算上整个存储的虚拟机数量，大概有200台左右。目前，我们只能通过上述方式将恢复的虚拟机逐个恢复到用户的ESXI。因为是通过网络传输的，所以网络是整个迁移过程中的一个瓶颈。经过不断的调试和主机更换，还是达不到理想的状态。由于时间限制，我们最终决定在当前环境中迁移数据。

八。数据恢复摘要

1、故障总结；磁盘上所有坏磁道的规则如下:

经过仔细分析，不良轨道的结论如下:

-除了sn:yhj6leud上的一个自然坏磁道外，其他所有坏磁道都分布在RAID-6的q校验块中。

-大多数坏磁道区域显示完整的256个扇区，这正好是创建RAID-6时完整RAID块的大小。

-活动区域显示坏磁道，非活动区域的坏磁道可能不会出现。例如，如果热备盘的联机时间少于10%，坏磁道的数量将少于其他联机磁盘(热备盘的镜像将需要4个小时，其他有坏磁道的磁盘将需要大约40个小时)。

-其他非Q检查区域状况良好，无任何故障。

结论:

一般从上述坏轨规则的表现可以推断出，坏轨对控制器产生Q校验，当IO指令下发到硬盘时，可能是非标准指令，硬盘内部处理异常，导致有规律的坏轨。

2.数据恢复概要；数据恢复过程中坏磁道太多，备份数据需要很长时间。整体存储是因为坏磁道导致最终恢复的数据部分破坏，但不影响整体数据，最终结果在可接受范围内。

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

本文地址:https://www.pccv.com/servernews/11001920.html

部分内容和图片来自互联网。如有侵权，请联系删除。QQ:228866015