dns 解析错误 网站,网站做淘宝客赚钱吗,做弹弓教程网站,教学督导网站建设报告一、故障描述机房突然断电导致整个存储瘫痪#xff0c;加电后存储依然无法使用。经过用户方工程师诊断后认为是断电导致存储阵列损坏。整个存储是由12块日立硬盘#xff08;3T SAS硬盘#xff09;组成的RAID-6磁盘阵列#xff0c;被分成一个卷#xff0c;分配给几台Vmware…一、故障描述机房突然断电导致整个存储瘫痪加电后存储依然无法使用。经过用户方工程师诊断后认为是断电导致存储阵列损坏。整个存储是由12块日立硬盘3T SAS硬盘组成的RAID-6磁盘阵列被分成一个卷分配给几台Vmware的ESXI主机做共享存储。整个卷中存放了大量的Windows虚拟机虚拟机基本都是模板创建的因此系统盘都统一为160G。数据盘大小不确定并且数据盘都是精简模式。 二、备份数据将故障存储的所有磁盘和备份sss数据的目标磁盘连入到一台Windows Server 2008的服务器上。故障磁盘都设为脱机只读状态在专业工具WinHex下看到连接状态如下图所示(图中HD1-HD12为目标备份磁盘HD13-HD24为源故障磁盘型号为HUS723030ALS640)图一 使用WinHex 对HD13-HD24以底层方式读取扇区发现了大量损坏扇区。初步判断可能是这种硬盘的读取机制与常见的硬盘不一样。尝试更换操作主机更换HBA卡更换扩展柜更换为Linux操作系统均呈现相同故障。与用户方工程师联系对方回应此控制器对磁盘没有特殊要求。使用专业工具对硬盘损坏扇区的分布规律进行检测发现如下规则1、损坏扇区分布以256个扇区为单位。2、除损坏扇区片断的起始位置不固定外后面的损坏扇区都是以2816个扇区为间隔。所有磁盘的损坏扇区分布如下表只列出前3个损坏扇区ID号 硬盘序列号 第1个损坏扇区 第2个损坏扇区 第3个损坏扇区13 YHJ7L3DD 5376 8192 1100814 YHJ6YW9D 2304 5120 793615 YHJ7M77D 2048 4864 768016 YHJ4M5AD 1792 4608 742417 YHJ4MERD 1536 4352 716818 YHJ4MH9D 1280 6912 972819 YHJ7JYYD 1024 6656 947220 YHJ4MHMD 768 6400 921621 YHJ7M4YD 512 6144 896022 YHJ632UD 256 5888 870423 YHJ6LEUD 5632 8448 1126424 YHHLDLRA 256 5888 8704临时写了个小程序对每个磁盘的损坏扇区做绕过处理。用此程序镜像完所有盘的数据。 三、故障分析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字节校验大量的0扇区也无8字节校验。故可知原存储并未启用存储中常用的DA技术(520字节扇区。分区大小如下图(GPT分区表项底层表现涂色部分表示分区大小单位512字节扇区64bit)图二四、重组RAID1、分析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处在不缺盘的状态为最佳。五、验证数据1、验证虚拟机针对用户较为重要的虚拟机做验证发现虚拟机大多都可以开机可以进入登陆界面。有部分虚拟机开机蓝屏或开机检测磁盘但是光盘修复之后都可以启动。部分虚拟机现象开机如下图三2、验证数据库针对重要的虚拟机中的数据库做验证发现数据库都正常。其中有一个数据库据用户描述是缺少部分数据但是经过仔细核对后发现这些数据在数据库中本来就不存在。通过查询 master 数据库中的系统视图查出原来的所有数据库信息如下图四3、检测整个VMFS卷是否完整由于虚拟机的数量很多每台都验证的话所需的时间会很长因此我们对整个VMFS卷做检测。在检测VMFS卷的过程中发现有部分虚拟机或虚拟机的文件被破坏。列表如下图五 六、恢复数据1、生成数据北亚工程师跟客户沟通并且描述了目前恢复的情况。用户经过对几台重要的虚拟机验证后用户反应恢复的数据可以接受接着北亚工程师立即着手准备恢复所有数据。先准备目标磁盘使用一台dell 的MD 1200加上11块3T的硬盘组成一个RAID阵列。接着将重组的RAID数据镜像到目标阵列上。然后利用专业的工具UFS解析整个VMFS文件系统。2、尝试挂载恢复的VMFS卷将恢复好的VMFS卷连接到我们的虚拟化环境中的一台ESXI5.5主机上尝试将其挂载到的ESXI5.5的环境中。但是由于版本客户的ESXI主机是5.0版本原因或VMFS本身有损坏导致其挂载不成功。继续尝试使用ESXI的命令挂载也不成功于是放弃挂载VMFS卷。 七、移交数据由于时间紧迫先安排北亚工程师将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中。由于是通过网络传输因此整个迁移的过程中网络是一个瓶颈。经过不断的调试以及更换主机最终还是无法达到一个理想的状态由于时间紧张最终还是决定在当前的环境迁移数据。 八、数据恢复总结1、故障总结所有磁盘坏道的规律如下表 经过仔细分析后得出坏道的结论如下-除去SNYHJ6LEUD上的一个自然坏道外其余坏道均分布于RAID-6的Q校验块中。-坏道区域多数表现为完整的256个扇区正好当时创建RAID-6时的一个完整RAID块大小。-活动区域表现为坏道非活动区域坏道有可能不出现如热备盘上线不足10%坏道数量就比其他在线盘少热备盘的镜像4小时完成其他有坏道盘大概花费40小时-其他非Q校验区域完好无任何故障。结论通常情况经如上坏道规则表现可推断坏道为控制器生成Q校验向硬盘下达IO指令时可能表现为非标指令硬盘内部处理异常导致出现规律性坏道。2、数据恢复总结数据恢复过程中由于坏道数量太多以致备份数据时花费了很长世间。整个存储是由坏道引起的导致最终恢复的数据有部分破坏但不影响整体数据最终的结果也在可接受范围内。整个恢复过程用户方要求紧急我方也安排工程师加班加点最终在最短的时间内将数据恢复出来。后续的数据迁移过程中由我方工程师和用户方工程师配合完成。 九、项目成员 转载于:https://blog.51cto.com/sun510/2079772
