【服务器数据恢复】raid5磁盘阵列突然崩溃的的数据恢复案例
服务器数据恢复环境&故障:
某公司一台存储设备存放公司内部重要文件。存储设备上有一组由6块硬盘组成的raid5磁盘阵列。存储设备在正常运行过程中突然崩溃,管理员强制重启后无法找到存储设备,多次重启后还是找不到存储设备。
服务器故障分析:
经过数据恢复工程师和硬件工程师团队的检测和分析,初步判断这台存储设备故障原因应该是raid模块损坏。raid模块损坏故障包括raid信息丢失和raid模块硬件损坏。基于以往大量的案例经验,北亚企安数据恢复工程师团队判断该存储设备故障极有可能就是设备多次异常断电导致的。经过与用户方管理员的沟通得知这台存储在出现故障之前确实遭遇过数次非正常的断电关机,但每次断电后重启一切正常,因此未引起管理员的注意。即使存储设备崩溃后也没有意识到这次故障与以前设备多次异常断电有关系。
阅读全文
posted @ 2023-03-31 11:51
服务器数据恢复环境:
某公司信息管理平台,若干台VMware虚拟机共享一台存储设备,供内部使用,该存储设备中存放了公司大量重要数据。
服务器故障:
该存储设备运行时,管理员在存储网络中连接了一台Windows服务器,这台存储设备突然无法正常使用。管理员对该存储设备进行初步检查后发现该存储设备中的虚拟磁盘丢失,分区表丢失,重启该存储设备后故障依旧。由于该存储设备中的数据十分重要且没有备份,管理员不敢擅自进行操作。
服务器数据恢复环境:
某公司一台web服务器,存储网站程序和网站内容数据,部署的MySQL数据库。
6块硬盘组建的一组raid6磁盘阵列。
服务器故障:
服务器raid6中有3块硬盘离线,服务器崩溃。服务器上部署的MySQL数据库数据丢失,服务器上跑的网站关停,业务中断。用户联系我们数据恢复中心要求恢复服务器数据。
服务器数据恢复环境:
某品牌EVA系列某型号存储设备,采用的ESXI虚拟化系统,虚拟机存储的是mysql数据库。
服务器故障:
由于异常断电导致存储设备中的一台虚拟机无法启动,管理员发现虚拟机无法启动后再次重启服务器,但是该虚拟机依然无法正常启动。由于该虚拟机中的数据涉密极为重要,而且只能到现场进行恢复,于是用户方联系我们数据恢复中心寻求帮助。
北京某国企服务器中部署的Oracle 11g R2数据库被误操作执行了truncate table CM_CHECK_ITEM_HIS,表数据丢失,查询该表时报错,数据库备份不可用,表数据无法查询。
Truncate数据原理:表被Truncate后,ORACLE会在数据字典和Segment Header中更新表的DATA_OBJECT_ID,但是不会修改实际数据部分的块。由于数据字典与段头的DATA_OBJECT_ID与后续的数据块中的并不一致,所以ORACLE服务进程在读取全表数据时读取不到已经被TRUNCATE但是实际未被覆盖的数据。
服务器数据恢复环境:
某公司的一台NetApp某型号存储;
几十块磁盘组建两组存储池,两组存储池互为镜像;
存储池划分卷并映射到ESXI作为数据存储使用,卷内有数百台虚拟机。
服务器故障:
管理员操作失误导致卷丢失,卷内虚拟机无法访问。管理员对该NetApp存储进行检查后尝试恢复数据但是没有成功。
服务器数据恢复环境:
服务器+10个磁盘柜,每个磁盘柜24块磁盘;
9个磁盘柜的磁盘用来存储数据,另外1个磁盘柜用来存储元数据;
存储元数据的24块磁盘的组成结构:9组RAID1磁盘阵列+1组4盘位的RAID10磁盘阵列+4个全局热备盘;
存储数据的9×24=216块磁盘的组成结构:36组6盘RAID5阵列;36组RAID5磁盘阵列分为2个存储系统。
服务器故障:
存储数据的其中一个存储系统中一组RAID5阵列由于2块磁盘先后故障离线,该RAID5阵列失效,导致整个存储系统崩溃,无法使用。
服务器数据恢复环境:
MD1200磁盘柜+RAID卡创建的RAID5磁盘阵列,分配了一个LUN,LUN被划分为sdc1和sdc2两个分区。通过LVM扩容的方式,将sdc1分区加入到了root_lv中。sdc2分区被格式化为XFS文件系统。
服务器故障:
用户对服务器进行了重装系统的操作后,发现sdc磁盘分区改变,sdc2分区丢失,无法访问。
服务器数据恢复环境:
某公司一台DELL服务器,作为WEB服务器使用,安装的Windows Server操作系统,配置了SQL Server数据库;
采用了Xen Server虚拟化系统;
底层是通过raid卡,用4块STAT硬盘搭建的RAID10。
服务器故障:
服务器意外断电导致虚拟机磁盘丢失,虚拟机不可用。需要恢复SQL Server数据库。
服务器数据恢复环境:
几年前从一台物理服务器上迁移到ESXI上的虚拟机,在迁移完成后做了一个快照。
服务器故障:
某天工作人员误操作还原了几年前迁移完成后所做的快照,将这台虚拟机的数据恢复到几年前刚迁移完成时候的状态,近3年的更新的数据全部丢失。
某公司一台IBM某型号服务器共16块硬盘,管理员某天巡检的时候发现该服务器的10号和13号硬盘灯显示黄色,服务器宕机,服务器上跑的业务终止。
通过IBM storage manager查询服务器状态,逻辑卷状态报告“失败”;6号盘的物理硬盘状态报告“警告”,10号和13号盘报告“失败”。通过IBM storage manager将当前服务器的日志进行完整备份,在备份的同时分析日志内容,获得部分逻辑卷信息用于后期数据恢复使用。
服务器数据恢复环境:
某公司一台服务器,使用FreeNAS做iSCSI,借助另外两台服务器做虚拟化系统。此虚拟化系统安装有5台虚拟机,其中3台虚拟机比较重要:一台虚拟机部署了ASP.net、PHP,安装了SqlServer和mysql数据库;另一台安装的FreeBSD系统并部署了MySQL数据库;一台虚拟机存储的是代码和数据。
FreeNAS层采用的是UFS2文件系统;服务器建一个文件然后挂载到ESXi系统。
服务器故障:
服务器意外断电后重启,虚拟化系统无法连接服务器,UFS2文件系统出现问题,管理员试图修复文件系统,但是完成修复后ESXi系统无法识别原有的数据和文件系统。
服务器数据恢复环境:
某品牌ProLiant DL系列服务器,
6块SAS硬盘组成RAID5磁盘阵列,
WINDOWS SERVER操作系统,
存储了企业的内部文件。
服务器故障&分析:
服务器在发生故障前有过几次意外断电,每次断电重启后没有出现异常。直到最后一次断电重启没有成功,RAID报错,提示无法找到存储设备。进入RAID管理模块,执行任何操作就死机。管理员多次重启服务器后还是无法成功进入操作系统。
EVA系列存储常见故障:
1、RSS中多个磁盘掉线,超过冗余保护级别规定的数量。
2、加入新磁盘后迁移数据时,新磁盘存在物理故障(此时无法回退/前进)。
3、误删除VDISK或EVA initialize。
4、主机与存储无法连接,无法discover存储。
数据库故障:
Oracle数据库的ASM磁盘组掉线,ASM实例不能挂载。管理员尝试修复数据库但是没有成功。
数据库数据恢复方案:
数据库数据恢复工程师通过分析组成ASM磁盘组的磁盘底层数据,将ASM元数据提取出来做进一步分析,发现ASM存储元数据已经损坏,导致diskgroup无法挂载。数据库数据恢复工程师将ASM存储空间重组,然后导出ASM磁盘组里面的数据库文件,检测导出的数据库文件并进行恢复。如果经过检测确认数据库文件是完整的,就可以直接使用数据库文件启动数据库;如果数据库文件损坏,就需要解析底层的数据库文件并恢复。
服务器数据恢复环境:
一台某品牌PowerEdge系列服务器和一台PowerVault系列存储,上层是ESXI虚拟机文件,虚拟机中运行SQL Server数据库。
服务器故障:
机房非正常断电导致虚拟机无法启动。管理员检查虚拟机发现虚拟机配置文件丢失,所幸的是xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件没有丢失。管理员尝试恢复虚拟机,将原虚拟机的xxx-flat.vmdk删除后新建了一个虚拟机,分配了几百GB的精简模式和几百GBGB的快照数据盘,但是并没有将原虚拟机内的数据恢复出来。
服务器数据恢复环境:
四台服务器节点组成的VSAN集群;
每台服务器节点上有两个磁盘组;每个磁盘组由一块SSD硬盘+5块SAS硬盘组成,SSD做闪存,SAS做容量盘。
服务器故障:
其中一个服务器节点上的一个磁盘组中的容量盘出现故障离线,这个时候VSAN开始数据重构&迁移,在迁移还没有完成的时候机房停电。来电重启设备后发现该服务器节点上另外一个磁盘组中有两块容量盘故障离线,数据存储出现故障。虽然可以登陆VSAN管理控制台,但是所有的虚拟机都无法访问了。
浙公网安备 33010602011771号