当前位置: 首页 > 科技观察

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

时间:2023-03-19 23:05:38 科技观察

一、服务器数据恢复故障描述机房突然停电导致整个存储瘫痪,上电后存储仍然不可用。经用户工程师诊断,认为是存储阵列因停电损坏。整个存储是由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、数据恢复小结:由于数据恢复过程中坏道较多,备份数据时间较长。整个存储都是坏道造成的,导致最终恢复的数据有部分损坏,但不影响整体数据,最终的结果也在可接受的范围内。整个恢复过程中,用户要求紧急,我们也安排工程师加班加点,最终在最短的时间内恢复了数据。后续的数据迁移过程由我们的工程师和用户工程师共同完成。