标签：磁盘阵列 使用 案例 信息 数据存储 成功 依次 debug map
一、服务器数据恢复故障描述某公司的一台服务器数据恢复需求。该公司有一台emc的服务器，搭建了raid5磁盘阵列进行数据存储，有两块热备盘，因为服务器上有两块硬盘出现故障，但是热备盘中只有一块被成功激活，导致了raid阵列瘫痪，服务器的上层应用不可用。需要进行服务器数据恢复。
首先对客户的两块掉线的硬盘进行物理检测，如果发现物理故障，需要对物理硬盘进行修复，然后才能继续下一步数据恢复操作，在本次服务器数据恢复案例中，硬盘不存在物理故障及坏道。
在服务器数据恢复开始前需要将客户的所有硬盘进行镜像备份。由于客户的服务器硬盘不存在物理故障，因此直接备份即可。使用winhex将所有磁盘都镜像成文件，由于源磁盘的扇区大小为520字节，因此还需要使用特殊工具将所有备份的数据再做520 to 512字节的转换。
先对服务器底层raid组进行数据分析，以便通过基础raid信息重组阵列，恢复服务器数据。经过对raid阵列的分析发现，客户原服务器内的两块热备盘内均为空，没有写入任何数据（因此推断有一块热备盘虽然上线，但此时raid组仍然处于缺盘状态，数据并没有开始同步。）随后工程师依次分析到了整个raid5阵列上的条带大小，磁盘顺序等基础信息，开始进行raid重组。
根据上述分析的RAID信息，尝试通过北亚自主开发的RAID虚拟程序将原始的RAID组虚拟出来。但由于整个RAID组中一共掉线两块盘，因此需要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样，因此初步判断此硬盘可能是最先掉线的，通过北亚自主开发的RAID校验程序对这个条带做校验，发现除掉刚才分析的那块硬盘得出的数据是最好的，因此可以明确最先掉线的硬盘了。
由于LUN是基于RAID组的，因此需要根据上述分析的信息将RAID组重组出来。然后分析LUN在RAID组中的分配信息，以及LUN分配的数据块MAP。由于底层只有一个LUN，因此只需要分析一份LUN信息就OK了。然后根据这些信息使用北亚raid恢复程序，解释LUN的数据MAP并导出LUN的所有数据。
利用ZFS文件系统解释程序对生成的LUN做文件系统解释，发现程序在解释某些文件系统元文件的时候报错。迅速安排开发工程师对程序做debug调试，分析程序报错原因。接着安排文件系统工程师分析ZFS文件系统是否因为版本原因，导致程序不支持。经过长达7小时的分析与调试，发现ZFS文件系统因存储突然瘫痪导致其中某些元文件损坏，从而导致解释ZFS文件系统的程序无法正常解释。
上述分析明确了ZFS文件系统因存储瘫痪导致部分文件系统元文件损坏，因此需要对这些损坏的文件系统元文件做修复，才能正常解析ZFS文件系统。分析损坏的元文件发现，因当初ZFS文件正在进行IO操作的同时存储瘫痪，导致部分文件系统元文件没有更新以及损坏。人工对这些损坏的元文件进行手工修复，保证ZFS文件系统能够正常解析。
对修复后的文件系统进行解析并验证最新数据。经过客户服务器管理员的验证，确认服务器内所有数据被成功恢复，本次数据恢复100%成功。
标签：磁盘阵列 使用 案例 信息 数据存储 成功 依次 debug map
原文地址：https://blog.51cto.com/sun510/2493576
