
北亚
专业服务器数据恢复/存储/虚拟化/数据库数据恢复
一、关于文件系统的概述
首先在这里介绍一下物理区和本地区是什么意思,物理区就是物理上连续的磁盘空间,即通常意义上的分区。本地区是指VMFS管理的物理区内分为保留区和本地区,前面一部分是保留区,后面部分是本地区。
本地区又分为元文件区和数据区。元文件:与NTFS的元文件类似,属于FS的管理用数据。在VMFS里有6个元文件.VH.SF/.FBB.SF/.FDC.SF/.SBC.SF/.PBC.SF/.PB2.SF。
元文件区是6个元文件占用的所有空间,在本地区的前面部分;数据区是用于存放文件数据。datastore:从ESX服务器看到的VMFS存储空间。LV:logical—volume,所指的范围其实和本地区一样。即虚拟化卷。LVM逻辑卷组:用来管理跨disk的LV,相当于VMFS的总存储空间datastore。
二、关于6个元文件的作用概述
6个元文件的作用都有:
.VH.SF: volume header文件,承载了‘本地区(或者LV)’的大小、时间、块大小、块数等信息。
.FBB.SF:file-bitmap文件,承载了‘datastore’里的块使用情况的位图信息。
.FDC.SF:file-discriptor文件,承载了‘datastore’里所有文件、目录的结点信息。
.SBC.SF: subblock分配文件,承载了‘datastore’里所有小文件、目录的数据区。
.PBC.SF: point-block文件,指针文件,承载了大文件的额外指针(超出结点记录范围的地址)。
.PB2.SF: .PBC.SF的再扩展。
三、虚拟机删除数据,数据恢复方法
因虚拟机删除后空间被回收,数据会存在于自由空间中,根据entry中的位图将所有空闲子块全部提取出来,在自由空间中进行查找恢复,防止现有数据的干扰。虚拟机删除恢复是否可以恢含猛尺复的关键依据为磁盘头部是否还存在,若存在可进行虚拟磁盘的拼接工作。
对硬盘进行检测:
对故障硬盘进行检测是否有硬件故障,如果有硬件故障,尝试对磁盘进行修复。
对硬盘镜像:
将磁盘在只读模式下进行磁盘镜像,之后恢复过程均使用镜像文件进行,防止磁盘的二次破坏。
1、虚拟机删除之后,提取pbc自由空间
分析每块组中子块的数量,分析谈高每个area中entry的数量,分析元文件头部的大小,分析子块大小,分析area的数量,根据entry特征值,分析entry的大小。根据entry中的位图信息,使用北亚虚拟化恢复工具提取VMFS卷的自由子块。
2、分别筛选子块
解析每个块第一条指针至数据区,意在判断丢失虚拟磁盘头部是否存在,如果存在则进行虚拟机知激的拼接工作。
3、遍历所有类型的子块,判断第一条指针是否为磁盘头部
使用北亚虚拟化软件分析工具判断每个类型子块第一条在指针是否为磁盘头部,及头部类型如(MBR、GPT、EXT4、LVM、Sparse、SeSparse)等,并将判断结果保存至数据库中,数据库只记录磁盘类型和磁盘头部所在位置,需根据丢失虚拟机大小、文件系统等判断是否有符合丢失磁盘特征的头部。
4、拼接虚拟机
对符合特征的磁盘头部进行分析,按照文件系统存储结构进行寻址拼接,计算出需要匹配数据块的特征值和该数据块在磁盘中的位置,以及特征值在数据库内的偏移位置。
根据需要修复的文件系统特征值和位置,使用自主研发的专业分析工具进行匹配符合结构的数据块。
根据匹配结果及该数据块在子块中的连续性,使用自主研发的专业分析工具将正确的数据块进行拼接。
首先认为是不可访问的虚拟机被锁住了,使用如下命令行去查询哪个esxi主机锁住了虚凳蔽拟机文件(命令行仅供参考)
输出结果如下(输出结果仅供参考):
的确出现了锁住该虚拟机的esxi主机的mac地址,然后找到该mac对应的esxi主机,ssh登录到该esxi主机,运行如下命令查询是否运行虚拟机
命令输出结果为空,即该esxi主机没有运行任何虚拟机,客户说该主机已经重启过。
阶段2:
通过上面的验证,说明虚拟机不是因为被锁住而无法访问虚拟机。SSH登录esxi主机,使用vi查看虚拟机的日志文件vmware.log,发现文件无法打开,复制vmware.log到其它目录或下载到PC电脑,都报读取错误。
查看vmkernel.log日志,发现如下错误信息:
5762cd03-0df4b321-83bd-e8611f13fece对应的volume即无法访问虚拟机所在的存储空间。通过google进行搜索查询关键字,从官方kb库说明可能是由于vmfs文件系统元数据出现了内容不一致,因此导致这个卷下的部分虚拟机能正常使用,而部分虚拟机或文件无法正常访问。
问题解决步骤
使用esxi自带的命令行解决该问题,或谈需要做如下准备:
迁移正常的虚拟机到其它存储空间
从所有esxi主机卸载有问题的存储
把无法访问的虚拟机从清单中移除
使用如下命令行检查存储是否存在extent (该命令不支持extent存储)
经过以上准备后,使用如下命令进行检查vmfs文件系统元数据检查:
……
经过检查后,vmfs元数据的确存在错误,使用如下命令进行修复:
…….
从修复命令输出可以获知部分错误已经修复,然后浏览存储,重新注册无法访问的虚拟机到目录清单,然后虚拟机就能正常打开电源,衫粗碰问题解决!
VMware虚拟机设备信息:1、VMware虚拟机(数量:40-50组占用空间:1.8TB)
2、VMware虚拟机——ESX SERVER共享一台IBM DS4100存储
VMware虚拟机故障描述:
工作人员在使用过程当中,由于vc里报告虚拟磁盘丢失,通过ssh到ESX中执行fdisk -l查看磁盘,storage已经无分区表。经过重启所有设备后,ESX SERVER均无法连接到DS4100所在的STORAGE。
通过对管理员的咨询了解到,在该存储网卖脊络里曾连接一台windows 2003服务器。
VMware虚拟机故障分析:
由此我们可推测,有可能是那台windows 2003通过对storage的独享 *** 作导致了vmfs卷损坏。
1、以整个存储做分析发现分区表清0,有55aa有效结束标志,有硬盘ID标志。
2、从前向后查看,发现一个NTFS卷,且无任何数据。我们通过对这个NTFS卷的BITMAP分析,得知大小约为1.8T(全部空间),3G左右位置占用部分空间,0.9T附近占用部分空间,但总占用空间不超过100M。
3、针对VMFS卷进行分析,发现在原1.8TB的磁盘里有2组VMFS分区,第2组是对第一组的extend,第一组约1.5T,第二组约300GB,因NTFS分区并未写数据到第二个VMFS分区里(最后一个扇区的DBR备份没有覆盖有用数据),所以重点在于第一个VMFS分区。分析第一组VMFS,卷头结构丢失,一级索引、二级索引均存在,NTFS覆盖的数据区正好是某组虚拟机的临时内存镜像,损坏也无妨。
VMware虚拟机数据恢复步骤:
第一步:对整个STORAGE进行镜像备份。
第二步:分析后,连接两个VMFS分区,直接按照VMFS分析组织方式提取所有VMDK及配置文件。
第三步:通过nfs直接迁移回ESX SERVER。
注:因本例中已对故障存储做了安培扮全备份,修复中同时直接重建第一组VMFS卷头,索引列表、分区表等信息,直接附加在ESX SERVER环境,算是第二个方案。
VMware虚拟机数据恢复结果:
历经两天时间,已将数据成功提取,经用户验收,数据可正常读取无误,至此数据恢复工作结束。
VMware虚拟机 *** 作小贴士:
1、本例中依然是因为光纤环境互斥不当导致的问题,实际上,应该是这个卷在WINDOWS系统做了重新分区,并格式化成了NTFS,之后又对分区做了删除 *** 作。因ESX VMFS的互斥不依赖于硬件,只依赖于 *** 作系统驱动层,所以在其他服务器接入存储网络时一定要小心,尽量考虑好存储分配权限。
2、ESX因便捷的信息集中管理,真正使用中往往数据特别重要,一定要做好备份工作,并考虑损坏时迁移的中中渗方便性。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)