硬件数据恢复案例

送修时间

：

故障描述

：IBM V7000存储挂载在一台WINDOWS2003服务器上使用，存储7TB的空间只划分为一个分区，分配盘符F盘,有一天突然服务器DOWN机后客户重启服务器，在系统启动的时候操作系统自动对F盘进行磁盘扫描修复,但修复过程进行了12个小时仍然没有完成,这时客户强制关机并断开服务器与存储的连接，启动操作系统后再连上存储，能出现F盘的盘符，但打开的时候提示“文件或目录损坏且无法读取",查看分区属性变成了RAW格式.

IBM V7000存储挂载在一台WINDOWS2003服务器上使用，存储7TB的空间只划分为一个分区，分配盘符F盘,有一天突然服务器DOWN机后客户重启服务器，在系统启动的时候操作系统自动对F盘进行磁盘扫描修复,但修复过程进行了12个小时仍然没有完成,这时客户强制关机并断开服务器与存储的连接，启动操作系统后再连上存储，能出现F盘的盘符，但打开的时候提示“文件或目录损坏且无法读取",查看分区属性变成了RAW格式.

检查恢复

： 第一步:为了确保数据的100%安全在恢复之前首先对源存储做一份原始数据备份,联系硬件厂家工程师，用IBM V7000的卷镜像功能通过光纤交换机将整个卷镜像到一台IBM DS4800存储上,之后的所有操作都在备份上面进行. 第二步：对镜像卷进行底层分析，发现故障点是MFT表自身的文件记录的的80属性DATARUNS操作系统自检时被截断（由于该分区内的文件数量非常巨大达到了2140多万个文件,MFT文件本身就达到了20多G，且MFT文件有大量碎片） 第三步采用两种方式同时进行数据恢复操作： A、用数据恢复软件扫描分区内的数据，但尝试过两种数据恢复软件进行了全盘扫描，扫描结果都不理想，原本有6T多的数据，扫描出来只能见到2T多的数据,并且目录结构混乱。估计是文件数量太多的原因。 B、采用手工分析收集所有的MFT表碎片信息，根据收集的碎片作息改写MFT的80属性DATARUNS；这种方式非常耗时费劲，但效果非常好,经过不断的努力成功的拼接起所有MFT碎片，通过软件打开分区，可以完整的看到6T多的数据，目录结构完整。 第四步：导出数据，先是花了一晚上的时间导出了2T多的Oracle数据库文件，经过软件公司验证数据库恢复的非常完美;接下来导出剩下的文件，剩下的文件都是些零碎的小文件导出的速度很慢，共计花了8天的时间将剩下的数据完整导出。