扬州某企业，ibm 3650m4 服务器，故障灯报错，服务器无法启动检测后发现硬盘报错，5块300g sas盘有两块报错。
检测结果：服务器使用win2008 系统，用于公司数据库和文件服务器，0号和3号硬盘报错，5块盘组raid5，无热备。
恢复结果：兆柏工程师检测后发现，3号硬盘最后损坏，直接检测3号盘，发现有大量坏道，使用pc3000 sas修复后数据恢复正常。然后更换硬盘后将数据回写后，系统启动正常，客户非常满意。

1、磁盘阵列处于降级状态时未及时rebuild磁盘阵列：
RAID磁盘阵列的数据安全冗余原理是利用空余出的部分空间实现的，当阵列中有成员盘下线后便无法继续提供冗余存储。如果此时未能及时更换新磁盘并rebuild整个卷的话一旦raid阵列中其他成员盘发生离线行为将导致整个raid卷无法工作，这也是在数据恢复工作中遇到较多的故障类型。
2、raid阵列控制器故障：
控制器在磁盘阵列中充当着操作系统与物理硬盘之间的链接纽带，并且每组不同的磁盘阵列中的硬盘数量、容量大小、raid级别、校验方式等raid信息都各有不同，这些信息有的存储于硬盘，有的存储于阵列卡或者二者都有存储。如果控制器出现故障一般情况下无法进行raid信息的还原，即使能够还原raid结构再次重建raid阵列也无法进行数据恢复。
3、固件算法缺陷：
RAID的创建、重建、降级、保护等工作在控制器的实现上是非常复杂的算法，当然这里面的复杂更多地是提供尽可能万无一失的无漏洞算法，尽管厂商不会轻易承认控制器的BUG，但毫无疑问，这些问题在任何一款控制器上都无法避免。因为固件算法上BUG，可能会产生很多无法解释的故障。比如在部分服务器数据恢复案例中，有一些早期生产的DELL 2950服务器，会有RAID一块盘OFFLINE后故障盘与报警灯不一致的情况，导致客户在更换故障盘REBUILD时拔错盘，整个RAID组崩溃。
4、IO通道受阻导致RAID掉盘：
RAID控制器在设计时为了数据的绝对安全，会尽可能避免写数据到不稳定的存储介质上，这样，当控制器与物理硬盘进行IO时，如果时间超过某个阀值，或不满足校验关系，便会认为对应的存储设备已不具备持续工作的能力，但会让其强制下线，通知管理员尽快解决问题。这种设计的初衷很好，同时也是正确的设计方式，但对于如物理链接线路松动，或因硬盘机械工作时反应超时（可能硬盘还是完好的）等随机原因对控制器而言无法分辨设备是否具备和之前一样的稳定状态，所以很不在意的某些小环节，便会导致RAID卷出现故障，此类故障的发生概率极大，而且无法避免。这也是大多数RAID出现故障后，硬盘并未有故障的原因，我们好多数据恢复服务的客户会因此质疑服务器厂商，实际上是有苦难言的，一定程度上，越是设计安全的控制器，越会发生此类现象。
5、控制器的稳定性：
RAID的控制器在ONLINE状态下(无离线盘)工作是最稳定的，相对而言，当部分硬盘损坏(可能是逻辑故障)后离线，控制器便会工作在一个比较吃力的状态，这也是好多中低端的RAID控制器在一块盘离线后读写性能急速下降的原因。控制器的负载太重便会极大地增加数据吞吐时出现IO滞留的可能性，从而导致如上面第4点提及的RAID离线。一个不具备高速硬件处理芯片，不具备高速缓冲的控制器发生这类故障的概率要高得多。为了避免出现故障后数据恢复带来的业务停顿与额外开销，还是尽量不要选择这类磁盘阵列控制器。
6、阵列中硬盘故障：
多数管理员认为只要正常工作的磁盘阵列中就不会存在损坏的硬盘，因为raid阵列中一旦有硬盘损坏后阵列会踢损坏硬盘下线，然而实际上并非如此。一组RAID卷在工作很长时间以后也很少会读到物理硬盘的所有磁盘空间，同一时间更是不可能。部分情况下，硬盘会在没有读到的区域或者以前读取是良好的区域产生坏道，这类坏道因为没有读写过，所以在控制器看来是好的。产生这种坏磁道的最直接危害是在REBUILD过程中。当一块物理硬盘离线后，通常所有的技术人员及官方资料都会写尽快做REBUILD，但如果其他硬盘存在这类平常不知的坏磁道，REBUILD又都是对全盘做全面同步，就一定会读写到那些坏道，这时候REBUILD没完成，新盘无法上线，因旧盘里又发现了坏道，便会导致RAID又多出一些下线的硬盘，这样就可能会导致RAID出现故障，无法自行进行数据恢复了。
7、人为误操作：
涉及数据恢复的数据灾难有相当一部分也是可以避免的，例如操作失误导致误拔了RAID里的硬盘、更换坏盘不及时、给RAID阵列除尘时忘了原来的顺序、不小心删除了原RAID配置等