服务器数据恢复环境：
某公司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、实现所有的数据恢复操作后，由管理员亲自对复原进去的数据进行验证，确认复原进去的数据残缺无误，本次数据恢复胜利。
发表回复