恢复案例. CASES OF RESTORATION

 

栏目导航
所在位置:首页 > 恢复案例
51不放假-太原某高新企业ESXi5.5虚拟机VMDK文件丢失恢复成功
更新时间:2020-05-04 作者:海马鑫好
详细介绍

虚拟机安全吗今天有这么一例。跟大家分享一下

设备情况:浪潮服务器 NF5280M4+浪潮存储AS5300存储柜

该存储由HGST-sas1.2tb*10快盘组成,由于客户公司技术维护操作失误导致存储连接不上,具体操作该技术已经记不清楚了。下面我们具体分析一下

我们跟客户沟通后得知该服务器安装EXSi5.5系统环境,连接存储。里面跑的5个虚拟机,其中有一个虚机是该企业的核心代码数据,不可丢失,运行CentOS6.5环境。

首先为了数据安全,我们把存储磁盘挂载到我们的镜像服务器环境中做了镜像操作以及物理测试(不会在客户的设备上面直接操作)

分析发现前面的分区信息都已经破坏,通过分析数据区确定了该存储是由的9盘位RAID5结构,剩余一盘作为热备盘使用。RAID参数为右异步,快大小256sec,开始扇区为0

 重组raid后,通过UFS软件解析VMFS文件系统失败,通过winhex分析发现前面关键信息已经破坏。通过Winhex分析发现1Gb存在FATNTFS的分区信息,解析发现里面有U盘大白菜PE系统,初步怀疑里面装进去个winpe引导系统.通过再次跟客户技术沟通,该技术表示装系统的时候用WINPE引导服务器后,可以识别的服务器下还挂载这一个8.2TB的磁盘,但是显示问号(?),再无做过其他操作,其实结合目前的分析结果来看,客户方技术的描述以及无关紧要了。

现在整个vmfs文件系统已经破坏,各个虚拟机的指针信息已经丢失,给恢复增加了难度。

再次跟客户沟通后确认了虚拟机大小(300G左右)以及环境后(centos),开始编写脚本在8.2TB空间内定位该虚拟机的存储位置,手工截取虚机碎片,合并制作xxx-flat.vmdk文件。

因为只有VMDK数据文件,虚拟机环境是无法正常加载的。于是我们新建一个跟同配置虚机,把制作好的VMKD文件上传到我们新建虚拟机测试平台打开电源顺利启动

客户远程验证数据代码无误,恢复顺利完成。

山西鑫远数据恢复 QQ: 115521023 395352121

全国免费咨询联系电话:18635136745 18634326745
山西(太原)鑫远数据恢复地址:山西省太原市南内环街赛格商务楼6层6002室
山西(太原)鑫远数据恢复官网http://www.0055aa.com
山西(太原)鑫远数据恢复:http://www.xyhdd.com  http://www.0351data.com 
山西太原服务器数据恢复: http://www.sxsql.com  http://www.360raid.com   http://www.xyraid.com

鑫远——专注数据恢复12年之久,上万恢复案例,总有一例与您所遇到的故障相同!

      鑫远数据安全与救援中心提供高端存储故障解决方案和数据救援方案
【HP EVA 】【EMC VNX系列】 【IBM V系列】
【DELL EQ系列】【SAN 小型机 【NETAPP系列】以及【虚拟化 超融合架构】

再次提示:在数据发生丢失时候一定要保护好现场,不要盲目的对损坏的硬盘或文件进行任何操作,并马上联系专业人员进行处理,以免您的数据彻底消失。

山西太原鑫远数据恢复中心是国内专业从事数据恢复的公司之一,其中的RAID实验室致力于磁盘阵列技术的研究。擅长各种软件、硬件的RAID5、RAID0磁盘阵列数据恢复 。经过多年研究掌握了各种从SAN到NAS和CAS,从高端到中低端磁盘阵列的算法。开发了磁盘阵列恢复工具,可脱离Raid卡,操作系统,把阵列中的数据完整的恢复出来。可恢复各类原因引起的磁盘阵列(Raid)丢失的数据,不受品牌和Raid级别的限制。已经解决国内大部分raid卡的算法,其中比较复杂的raid有:IBM 7133阵列的Raid5双循环算法,HP Raid卡和Compaq Raid卡的双循环算法,Raid1E算法,HP的Raid ADG和IBM的Raid的算法以及EMC DELL的阵列柜520卡的算法。
友情提示:由于客户数据泄密的事件屡有发生,原因就是有些数据恢复公司

不具备RAID恢复能力,而是把接到的活转给第三方公司来赚取差价,避免这个问题的办法就是要求数据恢复公司在现场直接恢复,或全程观看等候。



更多 >>更多产品
山西鑫远数据恢复,太原鑫远数据恢复,太原数据恢复,山西数据恢复,太原开盘数据恢复,太原服务器恢复,太原数据库修复,山西数据库修复,太原硬盘数据恢复,太原raid恢复,山西服务器数据恢复,山西硬盘数据恢复,山西数据库修复,山西数据恢复,RAID数据恢复,****病毒修复,固态硬盘恢复上门为某涉密单位海康
USBC首先不是中毒,但俗称“USBC病毒”此类故障大部分发生在FAT移动介质,比如TF卡,sd卡,cf卡等之类,有的会严重破坏文件系统,当然有的只是轻微的破坏造成目录偏移篡改之类的。网上说的chkdsk不要用,会改写原始的数据,那样会造成文件系统的二次损坏或者彻底恢复不了,我们要保持原样(保护案发现场)!!!在这里我们只说winhex,winhex才是王道!因为本案例用普通recovery软件是恢复不了的,我甚至都尝试过写WINHEX脚本全盘来做,做出的效果还是不够理想,中间还是会参杂别的视频信息,结果也是不敬人意上图出现乱码的目录也是因为文件系统偏移或损坏造成,起始DBR信息已经损坏,根据分析定位FAT表信息以及根目录起始位置确定了FAT表长度,以及簇大小64。手工回写了DBR信息,顺利展开了损坏的文件系统但是目录结构里面刚好缺失掉中午的视频素材,心情顿时凉凉的,怎么办。。。不是手工矫正文件系统后顺利拷贝客户需要的数据吗?以前都是这样的。这次失手了,难怪客户找了几家都没有恢复出来,去年年底的视频拖到了5月。一头又扎到十六进制里面,有种“识数寻踪”的赶脚(这是本书,有想了解的可以百度),根据以往恢复经验,大部分的MTS视频开始都是003F3F3F3F47400010(3F通配符),通过手工编写winhex脚本精准定位到数据的起始扇区20938752sec,成功截取了视频,大概2GB左右。通过播放软件播放,效果很差,隔几贞就会有别的视频镜头,很是卡顿。明显是视频碎片化存储了(本案例无数据写入,没有覆盖)。根据该视频的起始扇区推算出对应的簇号(326786)上面,根据分析文件系统的FAT表发现只破坏了前面一个扇区,FAT表基本完整,因此我们把思路转到了FAT表上面。FAT表中记录了每个文件的簇链结构;FAT表中记录的与数据区簇对应的表项,从0号标记开始至当前数据区所分配的簇的****数值,记录簇信息到FAT项;但是注意:其中0号~1号簇的值都是操作系统预先不留设定的特殊标记,而数据区的起始簇是2号簇。接下来我们的工作就是通过FAT表链对应的数据区,手工截取该视频碎片文件。。。工作量好大啊~通过FAT表链,分段截取视频碎片,合并成1.9GBmts文件,顺利播放。没有辜负我们付出的努力,同时也祝视频里面的新人新婚快乐~~视频恢复后无法正常播
山西鑫远数据恢复,太原鑫远数据恢复,太原数据恢复,山西数据恢复,太原开盘数据恢复,太原服务器恢复,太原数据库修复,山西数据库修复,太原硬盘数据恢复,太原raid恢复,山西服务器数据恢复,山西硬盘数据恢复,山西数据库修复,山西数据恢复,RAID数据恢复,****病毒修复,固态硬盘恢复51不放假-太原某高新企
上门为运城闻喜县委组

友情链接:中国数据库修复网 合肥数据恢复  淮南数据恢复 服务器数据恢复 太原数据恢复  大同数据恢复 

虚拟主机 中国名店网 深圳户口办理  数据人 自动秒收录