一、故障描述
由于客户方的人为误操作，将linux文件系统误装入到Ocfs2文件系统的数据卷上，导致原始Ocfs2文件系统被新格式化Ext4文件系统，据对两种文件系统格式化方式的了解，Ext4文件系统每隔几百兆会写入文件系统的原始信息的特性，用户的数据可能受到一定程度的破坏，但不会被破坏太多。
二、备份数据
1、将存储以只读模式映射给备份服务器。
2、使用dd，Winhex等专业备份工具将映射到备份服务器中的数据做全部镜像。
3、做完全部镜像后，将所有存储配置及链路还原至初始状态，之后数据恢复操作均不对原始硬盘做任何操作
三、故障分析
1、分析ocfs文件系统结构
找到ocfs2文件系统的超级块，通过分析超级块得出该文件系统的一些基本结构信息，然后通过客户给出的虚拟磁盘文件名称，查找到虚拟磁盘文件的目录项，继而找到所对应的所有一级索引项和二级索引项，并利用自主开发的文件系统解析程序，对已备份的数据进行文件系统解析。ocfs2文件系统的索引项结构如下。
一级索引项
二级索引项
2、修复文件系统
修复损坏的文件系统，对原始Ocfs2文件系统做一致性检测，并对损坏的区域进行人工修复。
四、恢复数据
1、生成数据
利用自主开发的针对Ocfs2不完整文件系统的解析工具对已修复的Ocfs2文件系统进行解析。并根据文件系统分析的结果，编写对应的数据提取程序，利用程序最大程度的恢复每一个虚拟磁盘文件，并对恢复的每一个虚拟磁盘文件进行一致性检测。
2、文件检测与修复
对恢复虚拟磁盘文件进行解析，验证虚拟磁盘文件是否有错误，并尝试修复。恢复其中的用户文件，对已恢复的用户文件进行一致性检测，并尝试修复损坏的文件。
五、验证数据
1、验证虚拟机
针对用户比较重要的虚拟机做验证，发现虚拟机大多都可以开机，可以到登陆界面。有部分虚拟机开机蓝屏或开机检测磁盘，但是进过光盘修复之后都可以启动。
部分虚拟机开机如下：
另外发现一台虚拟机磁盘文件恢复之后，通过解析发现该虚拟机中没有数据，继续对该虚拟磁盘文件进行分析，发现该文件索引项存在，但是索引结构并不多，数据量也很少，有可能存在认为清零或修改的情况，也可能虚拟机原本就没有多少数据。
2、验证数据库
针对重点虚拟机中的数据库做验证，发现数据库都正常。部分数据库可能与应用程序对接有的一定问题，经客户联系应用程序原厂的工作人员，经过修复之后，数据库都可以正常使用。
六、移交数据
由于时间紧迫，先使用专业工具“UFS”依次导出ocfs2中的虚拟机。然后安排工程师将R510服务器上的虚拟磁盘数据带到客户现场。
在现场使用网线将R510服务器接入到客户内部的网络当中，然后通过NFS共享，将虚拟机磁盘文件上传到客户的服务器上，然后通过ovm虚拟机管理工具进行虚拟机挂载。由于虚拟机数量不是很多，大小也不是很大，比较快的完成了数据移交。
七、数据恢复总结
整个数据恢复的过程中，对ocfs2文件结构的分析占用了比较多的时间，根据ext4文件系统格式化的特性，Ext4文件系统每隔几百兆会写入文件系统的原始信息，对客户数据造成了一定的破坏，但是这个破坏还是在可接受范围内的，数据恢复完成后客户也认可了我们的恢复成果。
整个恢复的过程因用户比较紧急，我司也安排工程师加班加点在最短的时间内将数据恢复出来。在后续的数据迁移过程中也是由我工程师和用户方工程师配合完成的。