共计 1372 个字符，预计需要花费 4 分钟才能阅读完成。
一、故障形容
因为客户方的人为误操作，将 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 文件系统每隔几百兆会写入文件系统的原始信息，对客户数据造成了肯定的毁坏，然而这个毁坏还是在可承受范畴内的，数据恢复实现后客户也认可了咱们的复原成绩。
整个复原的过程因用户比拟紧急，我司也安顿工程师加班加点在最短的工夫内将数据恢复进去。在后续的数据迁徙过程中也是由我工程师和用户方工程师配合实现的。
