当前位置: 首页 > news >正文

服务器数据恢复—Raid6阵列硬盘故障掉线,上层虚拟机数据如何恢复?

服务器数据恢复环境&故障:
一台由16块硬盘组成的raid6磁盘阵列。磁盘阵列中有一块硬盘因为物理故障掉线,导致服务器上层虚拟机无法正常使用,部分分区丢失,重启物理服务器后发现数据丢失。

服务器数据恢复过程:
1、将故障服务器上所有磁盘编号后取出,以只读方式将所有磁盘进行全盘镜像,镜像完成后将所有磁盘根据编号按照原样还原到原服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。基于镜像文件分析服务器上层数据,发现硬盘掉线导致了上层虚拟机文件系统被破坏,北亚企安数据恢复工程师分析后决定通过拼接文件碎片的方式恢复数据。
2、按照数据恢复工程师的数据恢复思路,需要对服务内现有的文件碎片进行拼接。拼接原理是通过fbb源文件的位图信息中的512M位图信息进行拼接。服务器上层虚拟机损坏的元文件指针类型不同会导致最终指向的数据索引位置也不同。本案例中虚拟机的元文件已经损坏,通过服务器现有数据是无法确认指针类型和指向。如果指针最终指向的位置不是fbb元文件区域,则通过此方案无法恢复数据。


3、北亚企安数据恢复工程师尝试逆向验证,假设上层虚拟机的损坏元文件指针确实指向fbb中的512M位图。按照这一思路扫描和拼接服务器底层数据,并在拼接的过程中不断检验数据。
4、在拼接数据时发现了两个目录。经过验证发现这两个目录十分相似,数据恢复工程师详细对比了这2个目录中的目录、文件、底层数据,发现两个目录中的数据完全一致,确认其中一个目录为备份数据。因此只需恢复任意一个目录中的数据即可完整恢复数据了。
5、在尝试拼接目录一的过程中发现文件系统被严重破坏,所有的文件都无法正常打开和使用。数据恢复工程师只能尝试拼接和恢复目录二。经过拼接和验证,目录二中大部分文件可以正常使用。
6、服务器数据恢复工程师继续对不完整的数据部分进行提取、拼接、手动修复,最终恢复出服务器内的所有数据。经用户方工程师的验证,确认服务器上层虚拟机可以正常使用,数据完整,本次数据恢复工作完成。

http://www.dtcms.com/a/108598.html

相关文章:

  • linux-firewalld防火墙允许端口
  • 【SLAM经典算法详解】Ubuntu 20.04部署LeGO-LOAM:从环境配置到KITTI适配,解决常见编译错误
  • 从零开发美颜SDK:美颜滤镜API的核心技术与实现
  • 多视图几何--立体校正--Fusiello方法
  • CMake学习--如何在CMake中编译静态库、动态库并在主程序中调用
  • rag精细化测试
  • 论坛系统的测试
  • win10 快速搭建 lnmp+swoole 环境 ,部署laravel6 与 swoole框架laravel-s项目1
  • Docker in Docker(Dind)
  • 深入解析 Git Submodule:从基础到高级操作指南
  • 电子电气架构 --- 控制器级架构
  • 基于HTML5的拖拽排序功能实现详解
  • Dify接口api对接,流式接收流式返回(.net)
  • Java迭代器【设计模式之迭代器模式】
  • C++ 中的类型处理与类型别名(二十六)
  • 车辆选择解决方案
  • 5.模型训练-毕设篇3
  • 字节跳动 UI-TARS 汇总整理报告
  • 核桃派2B:opencv python的 Canny findContours得到两个非常接近的轮廓,角点有几个像素的差距,如何处理?
  • 使用 Flutter 制作地图应用
  • 封装一套通用echats
  • 电子电气架构 --- 域控制器和EE架构关系
  • 时间字段前端VO接收用String,后端用Date
  • 防火墙和端口开关
  • Kafka和RocketMQ零拷贝对比
  • ABeam 德硕 | 中国汽车市场(2)——新能源车的崛起与中国汽车市场机遇与挑战
  • nuxt3 部署到服务器配置
  • 关于 数据库表关联查询(JOIN) 和 子查询(Subquery) 的详细对比,包括定义、语法、优缺点、使用场景及示例代码,并以表格总结关键差异
  • gitblit服务启动报错Cannot assign requested address: bind
  • Spring Boot3使用Spring AI通过Ollama集成deepseek