服务器数据恢复—OneFS文件系统下数据被删除的数据恢复案例

2024-09-05 21:44

本文主要是介绍服务器数据恢复—OneFS文件系统下数据被删除的数据恢复案例,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

服务器数据恢复环境&故障:
EMC NAS(Isilon S200),共3个节点,每个节点配置12块STAT硬盘。数据分两部分:一部分数据为vmware虚拟机(WEB服务器),通过NFS协议共享到ESX主机;另一部分数据为视频教学文件,通过CIFS协议共享给虚拟机(WEB服务器)。
外部入侵导致视重要数据被删除,其中包括MSSQL数据库,MP4、ASF和TS类型的视频教学文件。主要是删除了NFS共享的所有数据(虚拟机),而CIFS共享的数据则没有影响。

服务器数据恢复过程:
1、在Isilon的web管理界面操作将设备关机,将所有硬盘编号后取出,以只读方式将所有磁盘进行扇区级全盘镜像,镜像完成后将所有磁盘按照原样还原到原存储中,后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。

Tips:Isilon使用的是分布式文件系统OneFS。在Isilon存储集群中,每个节点都是一个单一的OneFS文件系统,因此Isilon支持横向扩展,且不会影响正在使用的数据。在集群工作时,所有节点提供相同的功能,节点与节点之前没有主备之分。当用户往集群中存储文件时,OneFS层会将文件分成128K的片段分别存到不同的节点中,而在节点层又会将128K的片段分成8K的小片段分别存到该节点的不同硬盘中。而用户文件的Indoe信息、目录项及数据MAP则会分别存储在所有节点中,这样可以确保用户不管从那个节点都可以访问到所有数据。Isilon在初始化时会让用户选择相应的冗余模式,不同的冗余模式所提供的数据安全级别也不一样(默认3个节点采用N+2:1模式)。

2、由于数据是被删除的,因此不用过多考虑存储的冗余级别,重点需要分析文件删除后,文件Indoe及数据MAP是否发生变化。和用户方沟通后得知被删除的虚拟磁盘文件都在64G或以上,并且存储中不存在其他类型的大文件。北亚企安数据恢复工程师编写程序扫描所有文件Indoe,将大小等于或者大于64G的文件Indoe都扫描出来。分析扫描出来的Indoe后发现Indoe中记录的数据MAP位置,其index指向的内容已不再是正常数据,并且所有节点上的Indoe均是同样的情况。仔细分析Inode,发现大文件的数据MAP会有多层(树结构),并且数据MAP中会记录文件的唯一ID,因此可以尝试找到文件最底层的数据MAP。尝试对文件最底层的数据MAP做遍历跟踪操作,发现最低层的数据MAP果然还在。
3、编写程序从文件的Inode中取出文件的唯一ID,然后对所有符合该ID的数据MAP做聚合。根据数据MAP中的VCN号做排序,发现每个文件的前17088项数据MAP都不存在,也就意味着每个文件的前17088项数据无法恢复。
4、经过换算发现丢失的数据MAP项数据量很小,而删除的全部是虚拟机的vmdk文件(NTFS文件系统),而NTFS文件系统的MFT基本都在3G的位置,也就是说只需要在每个vmdk文件的头部手动伪造一个MBR和DBR就可以解释vmdk里面的数据。编写程序解释扫描到的数据MAP,并根据VCN号的顺序导出数据,没有MAP的情况保留为零。
5、编写好程序后尝试导出一个vmdk文件,发现导出的vmdk文件比实际要小,并且vmdk中MFT的位置也与自身描述不符。随机验证了几个MAP发现都能指向数据区,而程序解释MAP的方式也都没有问题。考虑到各种可能性后,根据数据MAP进行验证,发现文件是稀疏的。
6、修改代码,重新导出刚才的vmdk,这次vmdk大小符合实际大小,且MFT的位置也在相应位置。手工伪造一个MBR,分区表以及DBR,再用开发的文件系统解释工具成功解释文件系统,导出vmdk里面的数据库及视频文件。
在验证了此vmdk中的数据库及视频文件没问题后,批量导出所有重要的vmdk文件,再手工一个一个的去修改每个vmdk文件。

7、所有重要的数据恢复完成后,由用户方安排工程师对恢复的数据做完整性及准确性检测,经过仔细验证,确定数据完全没有问题。

这篇关于服务器数据恢复—OneFS文件系统下数据被删除的数据恢复案例的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1140151

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

服务器集群同步时间手记

1.时间服务器配置(必须root用户) (1)检查ntp是否安装 [root@node1 桌面]# rpm -qa|grep ntpntp-4.2.6p5-10.el6.centos.x86_64fontpackages-filesystem-1.41-1.1.el6.noarchntpdate-4.2.6p5-10.el6.centos.x86_64 (2)修改ntp配置文件 [r

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于