服务器数据恢复—昆腾存储StorNext文件系统数据恢复案例

本文涉及的产品
云服务器 ECS,每月免费额度200元 3个月
云服务器ECS,u1 2核4GB 1个月
简介: 服务器数据恢复环境:昆腾某型号存储,8个存放数据的存储柜+1个存放元数据的存储柜。元数据存储:8组RAID1阵列+1组RAID10阵列+4个全局热备硬盘。数据存储:32组RAID5阵列,划分2个存储系统。服务器故障:数据存储的1个存储系统中的一组RAID5阵列中有2块硬盘先后出现故障离线,导致该RAID5阵列失效,整个存储系统崩溃不可用。

服务器数据恢复环境:
昆腾某型号存储,8个存放数据的存储柜+1个存放元数据的存储柜。
元数据存储:8组RAID1阵列+1组RAID10阵列+4个全局热备硬盘。
数据存储:32组RAID5阵列,划分2个存储系统。

服务器故障:

数据存储的1个存储系统中的一组RAID5阵列中有2块硬盘先后出现故障离线,导致该RAID5阵列失效,整个存储系统崩溃不可用。
本案例存储及文件系统架构如下:
01副本.jpg
注:Meta_LUN(元数据卷) Data_LUN(用户数据卷)

服务器数据恢复过程:
1、将故障RAID5阵列中的所有成员盘编号后从存储柜中取出,经过初步检测都可以正常读取。以只读方式将所有磁盘进行扇区级全盘镜像,在镜像过程中发现故障RAID5阵列中有1块故障硬盘存在大量的坏道区域,无法完成镜像。硬件工程师对故障硬盘进行开盘并更换固件,使用专业工具进行修复后可以继续镜像,但坏道仍然存在。镜像完成后将所有磁盘按照编号还原到原存储柜中,后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。针对没有故障的RAID阵列,进行存储层面的备份。
部分镜像文件:
02副本.jpg

2、基于镜像文件分析故障RAID5阵列中所有磁盘的的底层数据,获取到故障RAID的相关信息,利用获取到的raid信息虚拟重组原RAID5阵列,将RAID中的LUN生成镜像文件。通过分析底层数据,确定那块发现大量坏道的硬盘为后离线的硬盘,由于此硬盘存在大量坏道,可能对恢复结果造成影响。
3、登录该昆腾存储的管理界面,获取到StorNext文件系统中与卷相关的一些基本信息。
03副本.jpg

4、继续分析StorNext文件系统中的Meta卷和Data卷。StorNext文件系统中包含2个Data卷,每一个Data卷都是由多组RAID中的LUN组成的。分析这些LUN获取到这些LUN之间组合的算法规律,北亚企安数据恢复工程师利用得到的算法规律编写程序虚拟重组完整的Data卷。
04副本.jpg

5、分析Meta卷中的节点信息和目录项信息,分析Meta卷和Data卷之间的对应关系,针对一个Meta卷管理多个Data卷的情况,分析Meta卷到Data卷的索引算法。
文件节点:
05副本.jpg

目录块:
06副本.jpg

6、通过上面的分析&研究,获取到了恢复数据所需要的全部信息。北亚企安数据恢复工程师编写程序扫描Meta卷中的节点信息和目录项信息,然后通过解析目录项和节点获取完整的文件系统目录结构。解析每一个节点中的指针信息,将这些信息记录在数据库中。
文件信息:
07副本.jpg

北亚企安数据恢复工程师编写文件提取程序读取数据库,根据解析出的信息以及两个Data卷之间的聚合算法提取数据。
7、对提取出来的数据进行随机抽样检测,没有发现问题。将用户方所需要的文件提取到本地后移交数据。
8、数据移交完成后,经过检测后,用户方认可数据恢复结果。虽然有raid5阵列中的一块硬盘存在大量坏道,但核心数据没有被破坏。本次数据恢复工作完成。

相关文章
|
1天前
|
Oracle 关系型数据库 Linux
服务器数据恢复—磁盘掉线但热备盘没有启用导致RAID5阵列崩溃的数据恢复案例
某公司的一台服务器中的raid5磁盘阵列有两块磁盘先后掉线,服务器崩溃。故障服务器的操作系统为linux,操作系统部署了oa,数据库为oracle。oracle数据库已经不再对该oa系统提供后续支持,用户要求尽可能恢复操作系统和数据。 经过北亚企安数据恢复工程师检测,发现热备盘完全无启用,所有硬盘不存在明显物理故障,无明显同步的表现。
服务器数据恢复—磁盘掉线但热备盘没有启用导致RAID5阵列崩溃的数据恢复案例
|
2天前
|
存储 安全 数据挖掘
服务器数据恢复—正常断电后重启的服务器中Raid5阵列崩溃的数据恢复案例
服务器数据恢复环境: 一台某品牌DL380 G4服务器,服务器通过该服务器品牌smart array控制器挂载了一台国产的磁盘阵列,磁盘阵列中有一组由14块SCSI硬盘组建的RAID5。服务器安装LINUX操作系统,搭建了NFS+FTP,作为内部文件服务器使用。 服务器故障: 搬迁机房后,工作人员将服务器和磁盘阵列打扫了一下,连接所有线缆后,将服务器和磁盘阵列开机,发现服务器无法识别RAID,提示未做初始化。 北亚企安数据恢复工程师到达现场后对服务器和磁盘阵列进行简单的初检,经过初检发现数据丢失的原因是raid信息丢失,该RAID的冗余采用双循环的校验方式。
|
2天前
|
存储 弹性计算 监控
【阿里云弹性计算】深入阿里云ECS配置选择:CPU、内存与存储的最优搭配策略
【5月更文挑战第20天】阿里云ECS提供多种实例类型满足不同需求,如通用型、计算型、内存型等。选择CPU时,通用应用可选1-2核,计算密集型应用推荐4核以上。内存选择要考虑应用类型,内存密集型至少4GB起。存储方面,系统盘和数据盘容量依据应用和数据量决定,高性能应用可选SSD或高效云盘。结合业务特点和预算制定配置方案,并通过监控应用性能适时调整,确保资源最优利用。示例代码展示了使用阿里云CLI创建ECS实例的过程。
57 5
|
5天前
|
Linux KVM 数据库
服务器数据恢复—服务器误删除KVM虚拟机数据恢复案例
服务器数据恢复环境: 一台服务器安装Linux操作系统+EXT4文件系统。服务器上运行数台KVM虚拟机,每台虚拟机包含一个qcow2格式的磁盘文件和一个raw格式的磁盘文件。 服务器故障: 工作人员操作失误删除了服务器上的3台KVM虚拟机,虚拟机中运行数据库,需恢复误删除虚拟机中raw格式的磁盘文件。
服务器数据恢复—服务器误删除KVM虚拟机数据恢复案例
|
22小时前
|
存储 弹性计算 监控
【阿里云弹性计算】阿里云 ECS 性能优化秘籍:提升应用响应速度与资源利用率
【5月更文挑战第22天】阿里云ECS优化涉及实例规格选择、OS与应用配置、网络配置、存储优化及数据库连接池管理。合理挑选CPU和内存,关闭无关服务,利用EIP和负载均衡优化网络,选择合适存储类型,并通过监控工具进行性能分析和压力测试,以提升响应速度,优化资源利用率,降低成本,增强企业竞争力。示例展示了Java数据库连接池配置优化。通过持续探索和实践,可最大化发挥ECS潜力。
31 7
|
22小时前
|
弹性计算 监控 负载均衡
【阿里云弹性计算】ECS实例迁移实战:无缝迁移到阿里云的步骤与技巧
【5月更文挑战第22天】阿里云ECS实例迁移实战详解,涵盖无缝迁移步骤与技巧:选择合适迁移方案,如VPC或使用阿里云工具;创建目标环境,数据迁移及配置同步;测试验证功能正常,流量切换;选择低峰期,保证数据一致,实时监控,提升迁移成功率。本文为云平台迁移提供实用指南。
18 2
|
22小时前
|
弹性计算 安全 Shell
【阿里云弹性计算】阿里云ECS安全加固:从访问控制到数据保护的全方位策略
【5月更文挑战第22天】本文详述了阿里云ECS的安全加固策略,包括访问控制(如安全组设置和密钥对管理)、系统安全加固(如安全补丁更新和防病毒措施)以及数据保护(如数据备份、恢复和加密)。通过这些措施,用户可增强ECS安全性,保障业务安全稳定运行。
19 0
|
1天前
|
弹性计算 关系型数据库 MySQL
【阿里云弹性计算】从零搭建:基于阿里云ECS的高性能Web服务部署实践
【5月更文挑战第21天】本文介绍了如何使用阿里云ECS搭建高性能Web服务。首先,注册阿里云账号购买ECS实例,选择合适配置。接着,通过SSH连接实例,更新系统并安装Apache、PHP和MySQL。创建网站目录,上传代码,配置数据库和PHP。然后,启用Gzip压缩和KeepAlive,调整Apache并发连接数以优化性能。此教程为在阿里云上构建高效Web服务提供了基础指南。
57 5
|
1天前
|
弹性计算 Kubernetes Cloud Native
【阿里云弹性计算】阿里云ECS与容器技术融合:打造敏捷的云原生基础设施
【5月更文挑战第21天】阿里云ECS结合容器技术(如Docker和Kubernetes),助力企业构建敏捷云原生基础设施。ECS提供高性能服务器,支持容器快速部署和自动化管理,实现应用的高可用性和可维护性。通过二者协同,企业能打造高效、可扩展的应用,加速数字化转型。示例代码展示了在ECS上使用Docker和Kubernetes部署云原生应用的过程。
27 3

相关产品

  • 云服务器 ECS