服务器数据恢复环境：
某品牌存储，12块SAS硬盘组建RAID6磁盘阵列，划分一个卷，分配给几台Vmware ESXI主机做共享存储。
卷中存放了大量的Windows虚拟机，虚拟机通过模板创建的，系统盘大小一致，数据盘大小不确定，数据盘都是精简模式。
服务器故障：
机房意外断电，电力供应恢复正常后存储无法正常开机使用。经过用户方工程师诊断，初步判断是意外断电导致的存储设备中的磁盘阵列损坏。
服务器数据恢复过程：
1、尝试将故障存储中所有磁盘以只读方式做全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，避免对原始磁盘数据造成二次破坏。
2、在镜像的过程中发现大量损坏扇区。初步判断是因为这类硬盘的读取机制与常规硬盘不一样。尝试更换主机、HBA卡、扩展柜和操作系统，均出现相同的故障。与用户方工程师沟通后得知raid控制器对磁盘并没有特殊要求。
3、对硬盘损坏扇区的分布规律进行检测，发现以下规律：
a、损坏扇区以256个扇区为单位分布。
b、除了损坏扇区片断的起始位置不固定，后面的损坏扇区都是以2816个扇区为间隔。
所有磁盘的损坏扇区分布如下表（只列出前3个损坏扇区）：
4、北亚企安数据恢复工程师编写小程序对每个磁盘的损坏扇区做绕过处理，用此程序镜像完所有磁盘的数据。
5、基于镜像文件分析损坏扇区，发现损坏扇区呈规律性出现：
a、每段损坏扇区的区域大小为256。
b、损坏扇区分布为固定区域，每跳过11个256扇区就会遇到一个坏的256扇区。
c、损坏扇区的位置总是位于RAID的P校验或Q校验区域。
d、所有磁盘中只有10号盘有一个自然坏道。
6、通过分析扇区得知分区大小（扇区数）。按照RAID6的模式计算后得出的结果和raid控制器中保留的RAID信息区域大小吻合。根据物理硬盘底层表现，分区表大小为512字节，后面无8字节校验，大量的0扇区也无8字节校验。综合以上信息可以确定故障存储并未启用DA技术(520字节扇区）。
分区大小如下图(GPT分区表项底层表现，涂色部分表示分区大小，单位512字节扇区，64bit)：
7、重组RAID。
a、存储使用的是标准的RAID6阵列。整个存储被划分为一个卷并分配给几台ESXI做共享存储，因此卷的文件系统是VMFS。VMFS卷中存放了大量的Windows虚拟机，Windows虚拟机使用的NTFS文件系统，可以根据NTFS中的MFT的顺序分析出RAID条带的大小以及RAID的走向。
b、镜像完所有磁盘后发现{BANNED}最佳后一块硬盘并没有像其他磁盘一样有大量的坏道。这块磁盘中有大量的未损坏扇区，这些未损坏扇区基本上是全0扇区，可以判断这块硬盘是热备盘。
c、根据分析出来的RAID相关信息重组RAID。
重组完成后可以看到目录结构，但是不确定是否为{BANNED}最佳新状态。检测几个虚拟机发现有部分虚拟机的数据异常，初步判断RAID中存在掉线的磁盘。将RAID中的每一块磁盘依次踢掉后再查看刚才数据异常的地方，没有发现问题原因。
仔细分析底层数据发现问题不是出在RAID层面，而是出在VMFS文件系统层面。如果VMFS文件系统大于16TB，就会存在一些其他的记录信息，组建RAID时候需要跳过这些记录信息。再次重组RAID后查看以前数据异常的地方，发现问题已经解决了。
挑选其中的一台虚拟机做验证，将所有磁盘加入RIAD中后，发现这台虚拟机是可以启动的，但在缺盘的情况下启动就出现问题。因此可以判断该RAID在不缺盘的状态下为{BANNED}最佳佳。
8、验证虚拟机。
对重要的虚拟机做验证，发现大部分虚拟机可以开机进入登录界面。只有有少部分虚拟机开机蓝屏或开机检测磁盘，但是经过光盘修复之后都可以正常启动。
9、验证数据库。
针对重要虚拟机中的数据库做验证，数据库都正常。但是有一个数据库，据用户描述好像缺少部分数据，但是经过仔细核对后发现这些数据在数据库中本来就不存在。通过查询master数据库中的系统视图，查出所有数据库信息如下：
10、检查VMFS卷的完整性。
由于虚拟机数量较大，对每台虚拟机进行验证不太现实。所以我们对整个VMFS卷做检测，在检测VMFS卷的过程中发现部分虚拟机或虚拟机文件被破坏。
11、批量恢复数据。
准备目标磁盘，组建一个RAID阵列。将重组的RAID数据镜像到目标阵列上，然后利用北亚企安自研程序解析整个VMFS文件系统&提取VMFS卷。
12、移交数据。
在北亚企安数据恢复工程师的协助下，将恢复出来的数据迁移到用户方准备好的环境中。
阅读(272) | 评论(0) | 转发(0) |
