服务器数据恢复环境：
一台 IBM 某型号服务器上有 16 块 FC 硬盘组建 RAID 阵列。下层 linux 操作系统，ext3 文件系统，部署有 oracle 数据库。
服务器故障 & 检测：
服务器上跑的业务忽然解体，管理员发现服务器上有 2 块磁盘的指示灯显示黄色。
通过 IBM storage manager 查问服务器状态，发现服务器报告逻辑卷状态失败。物理硬盘状态为：一块盘报告“正告”，指示灯显示黄色的 2 块盘报告“失败”。通过 IBM storage manager 将以后服务器的日志残缺备份。北亚企安数据恢复工程师在备份服务器日志的同时剖析日志内容，获取数据复原所须要的逻辑卷信息。
服务器数据恢复过程：
1、将服务器中所有硬盘编号标记后从服务器内取出，由硬件工程师对所有硬盘进行硬件故障检测，通过检测发现 16 块盘均能够读取。针对 16 块盘的 SMART 状态进行检测，通过检测发现在 IBM storage manager 中报告“正告”的那块盘的 SMART 状态也报告为“正告”，后果统一。
2、在 windows 环境下将辨认进去的 FC 盘在磁盘管理器中标记为脱机状态，而后对这些磁盘进行扇区级别全盘镜像，将原始磁盘中的所有物理扇区镜像到 windows 零碎下的逻辑磁盘并以文件模式保留。在镜像过程中发现 SMART 状态报告为“正告”的磁盘镜像速度异样，windows 环境下的个别应用软件无奈对其进行操作，联合后面的检测后果能够判断该盘应该存在损坏 / 不稳固的扇区。
3、应用业余硬盘镜像设施对这块 SMART 状态报告为“正告”的磁盘进行镜像，在镜像过程中察看发现该盘的坏道并不多，然而存在大量的读取响应工夫长的不稳固扇区，于是调整镜像策略，批改“遇到坏道跳过扇区数”和“响应等待时间”等参数后持续对该盘进行镜像。
4、所有其余磁盘（除了 SMART 状态报告为“正告”的磁盘）镜像实现后，查看镜像过程中生成的日志，发现在 IBM storage manager 和硬盘 SMART 状态中均没报错的另外一块磁盘中也存在坏道，指示灯显示黄色的 2 块盘也存在大量不法则的坏道散布，依据坏道列表定位到指标镜像文件剖析发现，ext3 文件系统的一些要害源数据信息曾经被坏道毁坏，只能期待 SMART 状态报告为“正告”的磁盘镜像结束后，通过同一条带进行 xor 以及依据文件系统上下文关系手动修复被损坏的文件系统。
5、SMART 状态报告为“正告”的磁盘镜像实现，然而之前为了最大限度做出无效扇区以及为了爱护磁头而设置的拷贝策略会主动跳过一些不稳固扇区，所以该盘的镜像是不残缺的。调整拷贝策略，持续镜像被跳过的扇区，直到该盘所有扇区全副镜像进去。
6、将服务器中 16 块硬盘的物理扇区镜像实现后，在 windows 平台下应用软件将所有镜像文件全副开展。通过对 ext3 文件系统的逆向剖析以及对日志文件的剖析，获取到 16 块 FC 盘的盘序，RAID 的块大小，RAID 的校验走向和形式等信息。
7、利用这些 raid 相干信息虚构重组 RAID，RAID 重构实现后对 ext3 文件系统进行解析。
8、和用户沟通后，数据恢复工程师提取出了一些 oracle 的 dmp 文件，由用户尝试进行复原。复原的过程中 oracle 报告 imp-0008 谬误。北亚企安数据库工程师仔细分析导入 dmp 文件的日志文件，发现提取进去的 dmp 文件存在问题。
9、从新剖析 raid 构造，进一步确定 ext3 文件系统被毁坏的水平。又通过数小时的致力，北亚企安数据恢复工程师从新提取了 dmp 文件和 dbf 原始库文件。将复原进去的 dmp 文件移交给用户进行导入，这次导入一切顺利，没有报错。对复原进去的 dbf 原始库文件进行校验，后果所有文件均通过测试。通过认真核检测后，用户认可数据恢复后果，本次服务器数据恢复工作实现。