服务器存储故障：
某单位同友存储，存储设备中若干磁盘组建了raid5磁盘阵列。未知原因导致存储设备崩溃无法启动，raid5阵列上层的虚拟机全部丢失，其中存放了重要数据的3台虚拟机需要恢复。
服务器存储数据恢复过程：
1、磁盘镜像过程就不赘述了。通过与用户方的沟通以及对raid阵列的分析，获悉故障存储的存储结构：若干物理磁盘组成一个存储池，划分了多个lun，其中需要恢复的那3台虚拟机在lun1。
存储结构：
2、尝试对故障存储中raid5阵列进行分析重组，发现故该raid5阵列缺失2块硬盘，热备盘已经启用。
基于现在掌握的信息，可以还原当时故障发生过程：raid5阵列中第一块硬盘掉线后，热备盘自动启动替换掉线硬盘。当第二块硬盘掉线后，raid5阵列处于降级状态。当第三块硬盘掉线，raid5阵列崩溃。
通常这种情况是无法通过校验直接获取丢失硬盘的数据，只能尝试使用磁盘同等大小的全0镜像进行重组（使用全0镜像组建的raid，文件系统结构会被严重破坏，相当于每个条带都会缺失两个块的数据，所以一般情况下不建议使用全0镜像组建raid。）
重建raid：
3、通过重组的raid阵列提取LUN。通过对存储结构的进一步分析，数据恢复工程师获取到存储划分的MAP块。解析各个LUN的数据块指针，北亚企安数据恢复工程师编写数据提取程序提取LUN碎片，完成碎片提取后通过拼接碎片组建出完整的LUN。
提取LUN：
4、导出LUN内所有虚拟机并尝试启动，由于操作系统被破坏，虚拟机无法成功启动。
5、由于虚拟机无法启动，只能对虚拟机内的文件进行提取，但虚拟机内的多数文件被破坏严重，只有少部分文件可用，只好尝试其他数据恢复方案。
6、本案例中需要恢复数据的虚拟机中有mysql数据库，于是北亚企安数据恢复工程师尝试通过利用数据库底层存储的特殊性扫描数据页的方案来提取数据。在找到有数据库的虚拟机后，发现该虚拟机启用快照。父盘和快照文件都损坏的情况下常规合并操作无法完成，使用北亚企安自主研发的VMFS快照合并程序进行快照合并。
7、根据mysql数据页特征扫描数据页并导出（innodb引擎的数据库可以使用此方案，myisam引擎的数据库无“数据页”概念），分析系统表获取各用户表信息，根据各个表的id进行数据页分割。
8、因为数据库使用时间已久，表结构曾多次变更，在存储损坏后系统表中也有部分数据丢失，记录提取过程很不顺利。
9、首先获取最初版本数据库各个表的表结构：合并快照前的父盘因为写入较早，使用第一块掉线盘进行校验获取到这个文件的完整数据，然后提取出其中的数据库各个表的表结构。用户方提供了最新版的数据库建表脚本。
10、分别使用两组不同表结构对数据记录进行提取，导入数据恢复环境中的mysql数据库内，剔除各个表中因为表结构变更造成的乱码数据，最后将两组数据分别导出为.sql文件。
11、因为两个版本的数据库的表结构不同，所以联系了用户方的应用工程师进行调试，调试完成后导入平台，平台调试成功，用户方经过检测后认可本次数据恢复结果。
