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