【服务器数据恢复】linux ext3下mysql数据库被误删除的数据恢复案例
服务器数据恢复环境:
MYSQL数据库服务器,2块硬盘组建RAID1;
DATA卷存储了200多个数据库;
每天将每个数据库dump出后直接压缩成.gz包,然后将所有重要数据库的.gz 包放在一起压缩成一个总的.tar.gz包,覆盖原来的备份;
数据文件及备份文件全部存储于DATA卷上。
服务器故障&分析:
在一次常规的维护中,管理员不小心将DATA卷下的所有文件全部rm,删除后管理员马上关闭系统,再未做其它操作,但在删除那一刻有大量终端在访问此服务器。 阅读全文
posted @ 2022-11-09 11:09 北亚数据恢复 阅读(98) 评论(0) 推荐(0)
服务器电源损坏,用户找到一家电源销售商更换电源。可能是害怕损坏硬盘中的数据,电源销售商竟然把硬盘全部拔掉(只留下RAID卡)启动服务器进行测试,完成测试后再次连接硬盘启动服务器,发现RAID信息已经破坏。之后又做了一些操作(未知)。
我们中心拿到故障服务器时的故障表现:启动操作系统时提示无效的引导记录。用户要求恢复服务器中的数据,同时重新激活修复服务器的操作系统。
LINUX系统执行FSCK出错的故障表现:
1、无法挂载分区;
2、文件/目录丢失,根目录下生成/LOST+FOUND文件夹,里面有大量#XXXXXX类的文件和目录;
3、FSCK很快报错完成;
4、执行FSCK时有大量提示如修改节点、清0节点等操作。
数据库数据恢复环境:
LINUX EXT3文件系统,部署ORACLE数据库。
数据库故障&分析:
管理员在建立测试库时选错了服务器,在ORACLE数据库平台上CREATE了一套新库,创建至10%左右时发现异常,中止操作。
查看数据库目录发现只剩下SYSTEM2.DBF这一个库,其他的库(主要为SYSTEM1.DBF)丢失。
服务器数据恢复环境:
北京某科技大学,某品牌PowerEdge系列某型号服务器,6块SAS硬盘组成RAID5;
操作系统REDHAT,文件系统EXT3,分区采用LVM方式,存储着该大学某研究室运算1年多的重要数据。
服务器故障&分析:
未知原因导致服务器崩溃。管理员进入RAID控制界面检查发现1号盘与6号盘状态显示损坏。咨询服务器原厂工程师后,管理员强制上线6号盘,结果raid无法启动(操作系统也安装于此RAID)。管理员意识到问题严重性,马上停止所有操作。
数据库恢复环境:
联通海南分部信息平台,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。
浙公网安备 33010602011771号