硬盘故障： 硬盘存在物理坏道。 硬盘存在物理坏道的典型表现： 1、若硬盘为系统盘，故障表现通常为：操作系统异常缓慢、蓝屏，重启系统后引导失败并报告硬盘读取出错、系统自动反复重启。 2、若硬盘为移动硬盘，故障表现通常为：电脑无法加载盘符、提示硬盘需要格式化、频繁提示需要运行chkdsk来检查和修复磁盘、数据读取缓慢、死机。
Mysql数据库故障： Mysql数据库表记录丢失。 Mysql数据库故障表现： 1、Mysql数据库表中无任何数据或只有部分数据。 2、客户端无法查询到完整的信息。
硬盘故障： 硬盘固件区损坏。 硬盘固件区损坏的故障表现： 1、硬盘寻道正常但无法正确识别自身型号或容量。 2、硬盘可以正常识别自身型号和容量但无法读取。
UNIX系统常见故障表现： 1、存储结构出错； 2、数据删除； 3、文件系统格式化； 4、其他原因数据丢失。
服务器数据恢复环境： 两组分别由4块SAS接口硬盘组建的raid5阵列，两组raid5阵列划分LUN并由LVM管理，格式化为EXT3文件系统。 服务器故障： RAID5阵列中一块硬盘未知原因离线，热备盘自动激活上线替换离线硬盘。在热备盘上线过程中，raid5阵列中又有一块硬盘离线。热备盘同步失败，该raid阵列崩溃，LVM结构变得不完整，文件系统无法正常使用。
Oracle数据库常见故障表现： 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
mysql数据库故障： mysql数据库文件ibdata1、MYI、MYD损坏。 故障表现：1、数据库无法进行查询等操作；2、使用mysqlcheck和myisamchk无法修复数据库。
Linux操作系统是世界上流行的操作系统之一，被广泛用于服务器、个人电脑、移动设备和嵌入式系统。Linux系统下数据被误删除或者误格式化的问题非常普遍。下面北亚企安数据恢复工程师简单聊一下基于linux的文件系统（EXT2/EXT3/EXT4/Reiserfs/Xfs） 下删除或者格式化的数据恢复流程和可行性。
ESX SERVER常见故障： 1、因光纤存储设备接入了非ESX系统，共享未互斥，对存储进行了改写(重装系统，WINDOWS初始化，格式化等)，导致存储结构损坏。 2、升级或者变更卷时分区表或VMFS卷结构异常。 3、误删除VMFS存储中的VMDK。 4、VMFS格式化。
服务器存储数据恢复环境： 华为S5300存储中有12块FC硬盘，其中11块硬盘作为数据盘组建了一组RAID5阵列，剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用，存放的数据主要是Oracle数据库。 服务器存储故障： RAID5阵列中1块硬盘出现故障离线，热备盘自动激活开始同步数据，在同步数据的过程中又一块硬盘离线，RAID5阵列瘫痪，上层LUN无法使用。
一台HP EVA存储中有23块磁盘，挂接到一台windows server操作系统的服务器。 EVA存储上有三个硬盘指示灯亮黄灯，此刻存储还能正常使用。管理员在更换硬盘的过程中，又出现一块硬盘对应的指示灯亮黄灯，存储崩溃，无法使用了。
某品牌服务器上有一组由两块SAS硬盘组建的raid0阵列，上层是windows server操作系统+ntfs文件系统。服务器上一个硬盘指示灯显示黄颜色，该指示灯对应的硬盘离线，raid不可用。
服务器存储数据恢复环境： 存储中有一组由12块硬盘组建的RAID6阵列，上层linux操作系统+EXT3文件系统，该存储划分3个LUN。 服务器存储故障&分析： 存储中RAID6阵列不可用。为了抢救数据，运维人员使用原始RAID中的部分硬盘重新组建RAID并进行了初始化。 初始化开始一段时间后，运维人员察觉到情况有异后强制终止初始化，这个时候初始化已经完成一半以上。数据部分已被不可逆的破坏。
Sybase数据库数据恢复环境： Sybase数据库版本：SQL Anywhere 8.0。 Sybase数据库故障&分析： Sybase数据库无法启动。 使用Sybase Central连接报错。 数据库数据恢复工程师经过检测，发现Sybase数据库出现故障的原因是：异常断电造成Sybase数据库无法回写正常数据，导致多个存储页数据不一致，系统表描述和存储表不一致，部分存储页底层数据完全杂乱。
Oracle数据库故障&分析： 一台Oracle数据库打开报错，报错信息： “system01.dbf需要更多的恢复来保持一致性，数据库无法打开”。管理员联系我们数据恢复中心寻求帮助，并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份，无法通过备份去恢复数据库。 “system01.dbf需要更多的恢复来保持一致性”，出现这个报错信息可能是由控制文件损坏、数据文件损坏，数据文件与控制文件的SCN不一致等原因所导致。对数据库文件做进一步检测&分析，结果发现sysaux01.dbf文件有坏块。修复并启动数据库后，很多查询报错，export和data pump工具也无法使用。查询告警日志并分析报错，发现就是sysaux文件损坏所导致的上述错误。从数据库层面无法修复数据库。system和用户表空间的数据文件都是正常的，可以尝试利用底层解析数据文件，恢复用户数据。
服务器存储数据恢复环境： 某品牌光纤存储上共有16块FC硬盘。存储上的卷映射到Linux操作系统上。Linux操作系统上运行Oracle数据库。 服务器存储故障&检测： 存储上2块硬盘故障灯亮起，存储映射到linux操作系统上的卷挂载不上，业务中断。
服务器存储数据恢复环境： 某品牌MSA2000FC存储中有一组由7块盘组建的RAID5阵列，另外还有1块硬盘作为热备盘使用。 基于RAID5阵列划分的几个LUN分配给小机使用，存储空间通过LVM管理，重要数据为Oracle数据库及OA服务端。 服务器存储故障： RAID5阵列中2块硬盘离线，唯一的热备盘成功激活，RAID5阵列还是变得不可用，上层LUN无法使用。
服务器数据恢复环境： 两组分别由4块SAS硬盘组建的raid5阵列，两组阵列划分的LUN组成LVM架构，格式化为EXT3文件系统。 服务器故障： 一组raid5阵列中的一块硬盘离线。热备盘自动上线替换离线硬盘，但在热备盘上线同步数据的过程中，又有一块硬盘离线，导致热备盘同步失败。该组raid阵列崩溃，LVM结构不完整，文件系统无法正常使用。
存储掉盘超过上限，lun无法识别。管理员重组存储的位图信息并导出lun，发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息，重新导出控制文件中记录的数据文件，发现这些文件的大小依然为0kb。
服务器存储数据恢复环境： 某单位一台某品牌型号为DS5300的服务器存储，1个机头+4个扩展柜，底层是2组分别由数十块硬盘组建的RAID5阵列。存储系统上层一共分了11个卷。 服务器存储故障&分析： 存储设备上一组raid5阵列上的2块磁盘出现故障，对应的硬盘指示灯亮黄灯，阵列崩溃，存储不可用。该组故障阵列上层存放的是Oracle数据库文件。
服务器数据恢复环境： 某品牌X3850服务器中有一组由数块SAS硬盘组建的RAID5阵列，该阵列中有一块盘是热备盘。操作系统为linux redhat，上面跑着一个基于oracle数据库的oa。 服务器故障： 服务器raid5阵列中有一块硬盘离线，但是热备盘没有成功激活，之后另外一块硬盘离线，RAID崩溃。
服务器数据恢复环境： 某品牌DL380服务器，服务器中三块SAS硬盘组建了一组raid5阵列。服务器安装Windows Server操作系统，划分了3个分区，D分区存放数据库，E分区存放数据库备份。 服务器故障： RAID5阵列中有一块磁盘出现故障，该硬盘对应的指示灯亮红色。RAID5阵列瘫痪，D分区不可识别，E分区虽然可以识别，但是拷贝备份文件报错。管理员重启服务器，RAID5阵列上离线的硬盘自动上线开始同步数据。同步还没有完成时管理员强制关机，之后再没有动过服务器。
某单位信息管理平台，数台VMware ESX SERVER共享一台某品牌DS4100存储。 vc报告虚拟磁盘丢失，管理员ssh到ESX中执行fdisk -l查看磁盘，发现STORAGE中的分区表不见了。重启所有设备后，ESX SERVER均无法连接到DS4100存储中的STORAGE。
服务器存储数据恢复环境： 华为品牌型号为OceanStor S2600T的存储设备，存储上有一组由24块4T容量的机械硬盘组建的RAID5阵列，作为存储池使用。 服务器存储故障&检测： 存储设备中raid5阵列上多块硬盘出现故障离线，raid5阵列失效，数据无法正常访问。 关机后将存储中所有硬盘标记&取出，硬件工程师对所有硬盘进行硬件故障检测。经过检测，没有发现存在物理故障的磁盘，都可以正常读取。
服务器上Ext4文件系统umount失败，工作人员使用fsck命令检查文件系统的一致性，结果导致Ext4文件系统mount不上（有时表现为目录变为文件）。报错提示信息：“mount: wrong fs type,bad option,bad superblock”。
虚拟化数据恢复环境： 一台虚拟机从物理机迁移到ESXI虚拟化平台，迁移完成后做了一个快照。虚拟机上运行了一个SQL Server数据库，记录了数年的数据。 ESXI虚拟化平台上有数十台虚拟机，EXSI虚拟化平台连接了一台EVA存储，所有的虚拟机都存放在EVA存储上。 虚拟化故障： 工组人员误操作将数年前迁移完成后做的快照还原了，也就意味着虚拟机状态还原到数年前，近几年数据都被删除了。 还原快照相当于删除数据，意味着部分存储空间会被释放。为了不让这部分释放的空间被重用，需要将连接到这台存储的所有虚拟机都关掉，需要将不能长时间宕机的虚拟机迁移到别的EXSI虚拟化平台上。
虚拟化数据恢复环境： SAN环境下通过iSCSI实现FreeNAS，FreeNAS采用的UFS2文件系统。物理存储架构在一台服务器上，另外两台服务器上安装ESXi虚拟化系统。整个存储建立一个稀疏模式的文件，并挂载到ESXi虚拟化系统上。ESXi系统上有5台虚拟机。 其中有三台虚拟机比较重要：第一台安装windows server操作系统的虚拟机作为网站服务器使用，部署了ASP.net+SqlServer和PHP+mysql两套架构；第二台虚拟机安装FreeBSD系统，部署Mysql数据库，供其它几台虚拟机使用；第三台虚拟机安装windows server操作系统，存放程序代码。 虚拟化故障： 一次异常断电后，ESXi虚拟化系统连不上存储。管理员发现FreeNAS上的UFS2文件系统出现问题，于是使用fsck命令修复文件系统。 虽然在修复完成后ESXi系统可以连上存储，但是ESXi系统无法识别到原来的数据存储和VMFS文件系统，管理员格式化VMFS后发现里面空无一物。
服务器虚拟化数据恢复环境： 某品牌720服务器中有一组通过同品牌、型号为H710P的RAID卡+4块STAT硬盘组建的RAID10磁盘阵列。上层部署XenServer虚拟化平台。1台Windows Server操作系统虚拟机，该虚拟机有2块虚拟磁盘（系统盘+数据盘），当作网站服务器使用。 服务器虚拟化故障： XenServer虚拟机不可用，虚拟磁盘中数据丢失。
服务器数据恢复环境： 一台服务器中有一组由4块SAS硬盘组建的RAID5阵列，上层安装linux操作系统统。分区结构：boot分区+LVM卷+swap分区（按照顺序），LVM卷中划分了一个reiserfs文件系统作为根分区。 服务器故障： 服务器操作系统在运行过程中由于未知原因崩溃，管理员重装操作系统后发现分区结构变为：boot分区+swap分区+LVM卷（按照顺序），LVM卷中文件系统位置有个空的reiserfs超级块。 用户方需要恢复reiserfs文件系统中所有数据，包含数据库、网站程序与网页、OA系统中所有办公文档。
服务器存储数据恢复环境： 一台某型号存储主机+扩展柜+FC磁盘。 服务器存储故障&检测： 磁盘故障导致该存储中LUN不可用，导致上层应用无法正常使用。
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
