【vsan数据恢复】vsan分布式存储瘫痪的数据恢复案例
vsan数据恢复环境:
一组4台服务器搭建vsan集群;
每台服务器配置有2组分别由6块硬盘组成的磁盘阵列,上层是虚拟机文件。
vsan故障:
在运行过程中,某一个节点的一块硬盘离线,vsan安全机制启动,开始重构&迁移数据。在数据迁移过程中机房意外断电,数据重构失败,服务器重启,该节点的另一组磁盘阵列中的2块磁盘由于异常断电引发故障离线,从而让整个分布式存储瘫痪,上层所有虚拟机无法访问。 阅读全文
posted @ 2022-12-30 11:52 北亚数据恢复 阅读(139) 评论(0) 推荐(0)
服务器数据恢复环境:
磁盘柜+RAID卡搭建riad5磁盘阵列;
Linux操作系统;
总共一个LUN,划分两个分区;:sdc1分区通过LVM扩容的方式加入到了root_lv中,sdc2分区格式化为XFS文件系统。
服务器故障:
用户为服务器重装系统后发现分区发生改变,原先的sdc2分区丢失,无法访问。
服务器故障:
用户误操作将linux文件系统误装入到Ocfs2文件系统的数据卷上,导致原始Ocfs2文件系统被格式化为Ext4文件系统。
因为Ext4文件系统每隔几百兆就会写入文件系统的原始信息,所以本案例中的原始Ocfs2文件系统中的数据可能受到一定程度的破坏,但不会太严重。
数据库恢复环境:
操作系统:windows server;
数据库:win_oracle_x64。
数据库故障&分析:
oracle数据库误truncate table,备份无法使用。
oracle数据库误操作导致数据丢失是比较常见的一种故障,如果有备份只需要恢复备份数据即可,我们中心数据恢复工程师接到的case多是无备份或者备份无法使用、还原报错等。
首先介绍下Truncate工作原理:正常情况下oracle会通过Segment Header及数据字典对表更新Data Object ID,实际上存储数据部分的块并未被修改,如果被truncate,那么oracle在读取全表数据时会因为数据字典和Data Object ID与实际存储的数据块内容不一致而不会读取被truncate的内容记录。
服务器数据恢复环境:
EMC某型号存储;
8块硬盘组成raid5磁盘阵列。
服务器故障:
raid5磁盘阵列中2块硬盘离线,服务器崩溃,上层应用不可用。
服务器故障:
某品牌Storwize系列存储中raid5阵列有一块硬盘出现故障离线,热备盘启用替换离线盘,开始同步数据。这时与离线盘同一组Mdisk中的另一块磁盘故障离线,热备盘同步失败,这组Mdisk失效,整个通用卷无法使用。用户联系我们数据恢复中心寻求帮助。
本案例中用户要求恢复的主要是dcm图像文件。
服务器数据恢复环境:
某品牌X系列服务器;
linux操作系统;
4块SAS接口硬盘组建raid5磁盘阵列。
服务器故障&检测:
服务器运行过程中由于未知原因突然瘫痪,用户为故障服务器重新安装操作系统,安装完成后发现数据丢失。联系我们数据恢复中心寻求帮助,需要恢复的数据包括:数据库、办公文档、代码文件等。
数据恢复工程师检测了故障服务器,发现用户的重装系统操作导致逻辑卷被修改,文件系统被破坏,出现空白超级块。
vSAN存储数据恢复环境:
某公司一台vSAN分布式文件系统存储设备;
VSAN存储采用了超融合架构,存储内总共有24块硬盘。
vSAN存储故障&初检:
由于未知原因关机重启,逻辑架构出现严重故障,上层虚拟机瘫痪,存储数据丢失。
服务器数据恢复环境:
某公司一组服务器:磁盘柜+raid卡,raid5磁盘阵列;
linux操作系统+XFS文件系统,共3个分区。
服务器故障:
服务器重装操作系统,完成操作后用户发现服务器的磁盘分区出现问题:一个分区消失,其他分区不可访问。
服务器数据恢复环境:
一台使用NTFS文件系统的服务器;
7块硬盘组成了一组raid5磁盘阵列。
服务器故障&初检:
raid5磁盘阵列磁盘故障离线导致服务器瘫痪。用户在处理掉线磁盘时只添加新的硬盘rebuild,并没有将掉线的3块硬盘从阵列中拔掉。
浙公网安备 33010602011771号