服务器数据恢复—重装系统导致reiserfs文件系统损坏的数据恢复案例

简介: 原始数据组织结构:几十MB的boot分区+数百GB的LVM卷+2GB的swap分区。LVM卷中划分了一个reiserfs文件系统,作为根分区。

服务器数据恢复环境:
一台服务器上有一组由4块SAS硬盘组建的RAID5阵列,采用的reiserfs文件系统。
原始数据组织结构:几十MB的boot分区+数百GB的LVM卷+2GB的swap分区。LVM卷中划分了一个reiserfs文件系统,作为根分区。

服务器故障:
服务器在运行过程中操作系统由于未知原因崩溃。服务器管理员重装系统后发现数据组织结构发生了改变:2GB的boot与swap分区+数百GB的LVM卷,LVM卷中文件系统位置有个空的reiserfs超级块。
需要恢复的数据是LVM卷中的reiserfs文件系统上所有用户数据,包含数据库、网站程序与网页、OA系统里的所有办公文档。

服务器数据恢复过程:
1、将故障服务器上所有硬盘编号后取出,经过硬件工程师检测后没有发现存在硬件故障和坏道。将所有硬盘以只读方式做完整镜像备份,镜像完成后将所有硬盘根据编号按照原样还原到原服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行,避免在数据恢复过程中对原始数据造成二次破坏。
2、服务器数据恢复工程师通过对全盘reiserfs树节点之间的关联确定原reiserfs分区位置。经过分析发现原来存储数据的文件系统的前2GB数据已经被覆盖。出现这个问题的原因应该是工作人员在为服务器重新安装操作系统时错误地将分区结构初始化,所以装好系统后无法导入LVM卷,于是试图通过reiserfsck修复。
Tips:reiserfs文件系统对文件系统中所有的文件(含目录)线性化后,再以文件key生成B+树。随着树不断增加节点,树的结构整体拉展并向整个磁盘的数据区做平滑迁移。所以顶级节点通常不会放在文件系统的最前面。
根目录的文件KEY号通常是最小的。从空间上看,前2GB空间中存放最多的应该是离根起始路径最近的key节点。由于用户数据目录层次较深,节点存在的可能性很高。前2GB被覆盖的数据已经无法恢复,且文件系统前面对整个树的索引全部丢失,加上reiserfs的树的抽象设计,重搭建树会很困难。
3、北亚企安数据恢复工程师使用自主开发的工具在整个原文件系统区域进行key节点扫描并导出所有节点。然后通过自主开发的工具重新排序所有叶节点、过滤(去掉之前删除文件丢弃的节点),重新生成二级、三级、四级等叶节点。选择分区前面2GB空间作为新树的结构区,并生成对应地址信息。
针对原树路径某节点丢失的情况,对其用自定义的key节点编号命名;如无法确定其父目录,暂加入/otherfiles下。
4、生成树索引信息,写入特定位置。根据这些信息,生成超级块,设置clear标志。在suse虚拟机下,创建快照,挂载修复好的卷,这时已经可以看到文件了。
5、在修复用的suse虚拟机下,挂载用于copy数据的目标硬盘,mkfs后将所有数据cp到目标盘。
6、用户方通过find命令整理所需数据,修正部分目录文件位置与名称。部分丢失的散文件,按大小与文件头标志查找,找到后移动及重命名。
7、处理完后验证数据。经过验证,用户方确认所有数据完整恢复。本次数据恢复工作完成。

相关文章
|
2月前
|
SQL 关系型数据库 MySQL
开源新发布|PolarDB-X v2.4.2开源生态适配升级
PolarDB-X v2.4.2开源发布,重点完善生态能力:新增客户端驱动、开源polardbx-proxy组件,支持读写分离与高可用;强化DDL变更、扩缩容等运维能力,并兼容MySQL主备复制及MCP AI生态。
开源新发布|PolarDB-X v2.4.2开源生态适配升级
|
2月前
|
IDE Java 编译器
java编程最基础学习
Java入门需掌握:环境搭建、基础语法、面向对象、数组集合与异常处理。通过实践编写简单程序,逐步深入学习,打牢编程基础。
221 1
|
2月前
|
数据采集 监控 API
告别手动埋点!Android 无侵入式数据采集方案深度解析
传统的Android应用监控方案需要开发者在代码中手动添加埋点,不仅侵入性强、工作量大,还难以维护。本文深入探讨了基于字节码插桩技术的无侵入式数据采集方案,通过Gradle插件 + AGP API + ASM的技术组合,实现对应用性能、用户行为、网络请求等全方位监控,真正做到零侵入、易集成、高稳定。
492 38
|
2月前
|
机器学习/深度学习 数据可视化 算法
sklearn 特征选择实战:用 RFE 找到最优特征组合
特征越多模型未必越好,过多特征易导致过拟合、训练慢、难解释。递归特征消除(RFE)通过反复训练与特征评分,逐步剔除不重要特征,提升模型泛化能力与效率。本文详解RFE原理,并用scikit-learn实战葡萄酒数据集,展示如何结合逻辑回归与随机森林进行特征选择,比较不同模型的筛选差异,并通过RFECV自动确定最优特征数量,辅以可视化分析,帮助构建更简洁、高效、可解释的模型。
189 1
sklearn 特征选择实战:用 RFE 找到最优特征组合
|
2月前
|
SQL 人工智能 关系型数据库
AI Agent的未来之争:任务规划,该由人主导还是AI自主?——阿里云RDS AI助手的最佳实践
AI Agent的规划能力需权衡自主与人工。阿里云RDS AI助手实践表明:开放场景可由大模型自主规划,高频垂直场景则宜采用人工SOP驱动,结合案例库与混合架构,实现稳定、可解释的企业级应用,推动AI从“能聊”走向“能用”。
862 39
AI Agent的未来之争:任务规划,该由人主导还是AI自主?——阿里云RDS AI助手的最佳实践
|
21天前
|
人工智能 前端开发 数据挖掘
AI学习全景图:从大模型到RAG,从工具到变现,一条从0到1的路线
告别碎片化学习!本文系统梳理AI知识五层结构:从基础认知到商业变现,提供完整学习路径与优质资源链接。帮你构建AI知识网络,实现从工具使用到能力落地的跃迁。
|
2月前
|
缓存 安全 Java
如何在Java中实现多线程编程
Java多线程编程有三种主要方式:继承Thread类、实现Runnable接口、实现Callable接口(结合Future获取结果),推荐使用Runnable避免单继承限制。通过线程池(如ExecutorService)可高效管理线程,提升性能。多线程共享资源时需注意线程安全,使用synchronized或Lock机制保证数据一致性。适用于并发执行、异步计算等场景。
205 1
|
2月前
|
存储 消息中间件 Kafka
Confluent 首席架构师万字剖析 Apache Fluss(二):核心架构
原文:https://jack-vanlightly.com/blog/2025/9/2/understanding-apache-fluss 作者:Jack Vanlightly 翻译:Wayne Wang@腾讯 译注:Jack Vanlightly 是一位专注于数据系统底层架构的知名技术博主,他的文章以篇幅长、细节丰富而闻名。目前 Jack 就职于 Confluent,担任首席技术架构师,因此这篇 Fluss 深度分析文章,具备一定的客观参考意义。译文拆成了三篇文章,本文是第二篇。
314 19
|
2月前
|
运维 数据安全/隐私保护
技术原理:CONNECT 与 TLS 构建可治理边界
CONNECT隧道通过HTTP协议建立至目标的加密通道,出站节点仅转发数据,不触达明文。端到端TLS保障通信隐私,策略基于元数据执行。实现隐私合规、精细管控与高效稳定三大核心价值。(238字)
|
2月前
|
存储 安全 Java
泛型在Java集合框架中的类型擦除机制是如何工作的?
泛型在Java集合框架中的类型擦除机制是如何工作的?
81 2

热门文章

最新文章