共计 968 个字符，预计需要花费 3 分钟才能阅读完成。
服务器故障：
用户误操作将 linux 文件系统误装入到 Ocfs2 文件系统的数据卷上，导致原始 Ocfs2 文件系统被格式化为 Ext4 文件系统。
因为 Ext4 文件系统每隔几百兆就会写入文件系统的原始信息，所以本案例中的原始 Ocfs2 文件系统中的数据可能受到肯定水平的毁坏，但不会太重大。
服务器数据恢复过程：
1、将故障服务器中的所有硬盘以只读模式映射给备份服务器，将映射到备份服务器中的数据做镜像备份。做完镜像后将所有硬盘依照原样还原到故障服务器，之后的数据恢复操作均在镜像文件上进行，防止对原始数据造成二次挫伤。
2、找到 & 剖析 ocfs2 文件系统的超级块，通过剖析获取到 ocfs2 文件系统的根本构造信息。通过用户提供的虚构磁盘文件名称找到虚构磁盘文件的目录项和对应的一级索引项和二级索引项。
3、利用北亚自主开发的 ocfs2 文件系统解析程序对备份数据进行文件系统解析。ocfs2 文件系统的索引项构造如下：
一级索引项：
二级索引项：
4、修复损坏的 Ocfs2 文件系统。对原始 Ocfs2 文件系统做一致性检测，北亚数据恢复工程师对损坏的区域进行人工修复。
5、应用北亚自主开发的针对 Ocfs2 不残缺文件系统的解析工具解析已修复的 Ocfs2 文件系统。
6、依据对 Ocfs2 文件系统剖析后果，北亚数据恢复工程师编写对应的数据提取程序复原每一个虚构磁盘文件，对复原进去的每一个虚构磁盘文件做一致性检测。
7、解析复原进去的虚构磁盘文件，验证虚构磁盘文件是否有谬误并尝试修复。
8、复原虚构磁盘文件中的用户文件，对已复原的用户文件做一致性检测并尝试修复损坏的文件。
9、验证比拟重要的虚拟机，虚拟机大多都能够开机进入到登录界面。有小局部虚拟机开机蓝屏或开机检测磁盘，通过光盘修复之后都能够失常启动。
局部虚拟机开机如下：
其中有一台虚拟机磁盘文件复原之后，通过解析发现该虚拟机中没有数据。持续剖析该虚构磁盘文件，发现该虚构磁盘文件索引项存在，然而索引构造并不多，数据量也很少，揣测可能存在人为清零或批改的状况，也可能该虚拟机本来就没有多少数据。
10、验证重点虚拟机中的数据库，发现数据库都失常。局部数据库与应用程序连贯呈现问题，用户分割应用程序厂商技术人员进行修复之后，数据库都能够失常应用。
11、通过数据恢复工程师和用户的亲自验证确认数据没有问题后，把所有复原进去的数据移交给用户。
