共计 1635 个字符，预计需要花费 5 分钟才能阅读完成。
服务器数据恢复环境：
某公司 Linux 零碎服务器；
共有两个分区：第一个分区是替换分区，第二个分区是 Ext4 文件系统。
服务器故障 & 剖析：
Ext4 文件系统不能 umount，管理员做 fsck 操作查看一致性，后果导致 Ext4 文件 mount 不上。报错信息：mount: wrong fs type, bad option, bad superblock。管理员分割咱们数据恢复核心进行数据恢复。
日志和数据不统一造成的失常文件系统数据被笼罩，这种故障常常在 Ext3、Ext4 文件系统产生，好在本案例中的.journal 日志文件留有缓冲，能够从.journal 日志文件里找到相应信息并粘贴回相应地位，达到重建原文件的目标。
Ext3、Ext4 文件系统有日志性能，本案例思考从.journal 日志文件中找到失落数据。
服务器数据恢复计划：
通过北亚服务器数据恢复工程师会诊最终敲定以下数据恢复计划：
1、通过.journal 日志文件里的超级块备份找到超级块，确定块大小。
2、通过.journal 日志文件里的超级块备份找到超级块，重建超级块信息。
3、通过.journal 日志文件找到目录节点，重建 (复原) 目录。
4、通过.journal 日志文件找到目录节点找到要复原的文件的节点信息，重建 (复原) 文件。
服务器数据恢复过程：
首先用工具关上 Ext4 文件系统，能够看到 0 -23 扇区的数据 (包含超级块和块组描述符) 被日志记录笼罩。Ext3、Ext4 文件系统的日志页以 C0 3B 39 98 结尾。如下图所示。
1、确定块大小：
超级块中有对于块大小的信息，能够从.journal 日志中查找超级块的备份。用工具查找失去.journal 日志中超级块的信息，其标记是“53ef”。查找超级块形式如下图所示。查看块大小办法如图 4 和图 5 所示。超级块 0x18-0x1B 处形容块大小，确定本案例块大小为 4KB。
通过超级块查看块大小如下图所示。
WinHex 模板编辑器也能够显示块大小，如下图所示。
2、重建 (复原) 超级块；
因为原文件系统超级块损坏，所以复原文件时须要把这部分超级块信息粘贴回去，即放在 2 号扇区开始，或 1024 字节处。
实现上述操作，超级块备份的某些中央与理论的超级块数值可能不统一，须要通过 WinHex 的模板管理器批改一下。本案例对超级块所在的块组作了批改，它在第 0 个块组里。如下图所示。
3、重建 (复原) 块组形容表：
因为局部块组形容表被毁坏，所以在.journal 日志文件里找到所有的块组形容表，并把它们粘贴回去。.journal 日志文件里，块组描述符表存储在超级块的前面。所以要找块组形容表时，能够先找到超级块。找到后将块组描述符表内容粘贴到 4096 字节处。
4、重建 (复原) 目录：
当要复原某个文件夹里的文件时，比方 kyproc 文件夹里的数据，发现这些文件夹在 WinHex 里是不能关上的状态，如下图所示。很显著这个目录损坏了，关上其节点信息，发现失常数据被日志填充，如下图 2 所示。
咱们找到它的上一级目录，即 var 文件夹，右击点“open”，关上看到 var 文件里的所有文件的目录信息。找到要复原的 kyproc 目录的信息，12 32 EE 00 是其 i - 节点号，10 00 示意其目录项长度，06 示意其文件名称长度，02 示意其文件类型为目录。如下图所示。
而后在 var 文件夹的目录块下查找 kyproc 目录的地位，如下图所示，标红的地位是找到的后果。此地位显示所在块号为 62399108。
依据所在块号，就能够定位 kyproc 目录相应节点的地位。因为人工补节点比拟繁琐，北亚数据恢复工程师关上.journal 日志文件，从外面找到其节点信息，把相应的信息粘贴回去。
上述办法能够重建 (复原) 目录，复原目录里的文件也是通过同样的办法从.journal 日志文件里找到相应的文件的节点信息，找到后粘贴回原来的地位，达到重建 (复原) 文件的目标。
5、实现所有的数据恢复操作后，由管理员亲自对复原进去的数据进行验证，确认复原进去的数据残缺无误，本次数据恢复胜利。
