【服务器数据恢复】EXT3文件系统的RAID5数据恢复案例
摘要： 
服务器数据恢复环境：
北京某科技大学，某品牌PowerEdge系列某型号服务器，6块SAS硬盘组成RAID5；
操作系统REDHAT，文件系统EXT3，分区采用LVM方式，存储着该大学某研究室运算1年多的重要数据。
服务器故障&分析：
未知原因导致服务器崩溃。管理员进入RAID控制界面检查发现1号盘与6号盘状态显示损坏。咨询服务器原厂工程师后，管理员强制上线6号盘，结果raid无法启动（操作系统也安装于此RAID）。管理员意识到问题严重性，马上停止所有操作。 阅读全文
服务器数据恢复环境：
北京某科技大学，某品牌PowerEdge系列某型号服务器，6块SAS硬盘组成RAID5；
操作系统REDHAT，文件系统EXT3，分区采用LVM方式，存储着该大学某研究室运算1年多的重要数据。
服务器故障&分析：
未知原因导致服务器崩溃。管理员进入RAID控制界面检查发现1号盘与6号盘状态显示损坏。咨询服务器原厂工程师后，管理员强制上线6号盘，结果raid无法启动（操作系统也安装于此RAID）。管理员意识到问题严重性，马上停止所有操作。 阅读全文
posted @ 2022-11-03 11:21 北亚数据恢复 阅读(24) 评论(0) 推荐(0)
数据库恢复环境：
联通海南分部信息平台，HP-UX小型机；
ORACLE数据库，卷文件系统为VxFS。
数据库故障&分析：
工程师误RM掉了重要ORACLE数据库，丢失了所有的数据表、UNDO、LOG等。 
服务器数据恢复环境：
某网站服务器，LINUX操作系统；
6块硬盘组建RAID5；
逻辑磁盘中只包含一个卷，文件系统为EXT3，存放所有客户的数码照片。
服务器故障&分析：
网站正常工作中卷突然离线，管理员检查服务器发现1号与4号两块硬盘指示灯显示黄色。致电服务器厂商售后，厂商技术人员提供的解决方案为随机选择一块报警的硬盘强制上线。
管理员选择4号盘强制上线，上线后可MOUNT，但很多目录打不开，某些目录下近几天的文件丢失。用户意识到问题的严重性后马上关机，没有做其他任何操作，联系我们数据恢复中心寻求帮助。 
服务器数据恢复环境：
新网企业邮件服务器；
组建RAID5，文件系统为REISERFS；
一个数据分区，存放上百万企业用户的邮件。
服务器故障&分析：
服务器在正常运行过程中，RAID突然OFFLINE。管理员检查发现故障服务器有两块盘报警，将其中一块盘强制上线后却发现卷无法挂载，于是执行FSCK并REBULD TREE，完成上述操作后卷仍然无法挂载。咨询多家数据恢复服务商均无法提供可行的解决方案，最终新网选择我们数据恢复中心进行数据恢复。 
服务器数据恢复环境：
某医院存储服务器，存储了十几年的CT照片等文件的备份；
8块硬盘中的7块硬盘作为数据盘组建RAID5，1块作为热备盘。
服务器故障：
医院方发现存储服务器中的数据不正常，找过多家数据恢复服务商对故障服务器做过恢复操作，具体操作不详。 
POWEREDGE系列某型号服务器；
LINUX系统+RAID5。
服务器故障：
管理员执行FSCK操作后LINUX系统无法MOUNT。 
服务器存储设备数据恢复环境：
EMC某型号中端存储设备，支持block，file和vvol三种服务类型；
存储设备连接了2台硬盘柜，2台硬盘柜上面有2组互相独立的POOL，共21块520字节的硬盘。
服务器存储设备故障：
工作人员的误操作将2组POOL上的部分数据卷给删除了，一共有5个数据卷被删除。 
突然断电造成Sybase数据库无法回写正常数据，导致多个存储页数据不一致，系统表描述和存储表不一致，并有一些存储页底层数据完全杂乱。 
北京某公司Oracle数据库误truncate table CM_CHECK_ITEM_HIS，表数据丢失，业务查询到该表时报错，数据库备份也不可用，表数据无法查询。 
某公司Ext4文件系统umount失败，管理员执行fsck检查一致性，结果Ext4文件mount不上(有时也表现为目录变成了文件)，报错信息：mount: wrong fs type, bad option,bad superblock。 
浙公网安备 33010602011771号