[数据恢复答疑]RAID里的硬盘可以互换槽位吗

版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
[问题]
在断电情况下，把已经配置好的RAID中的硬盘盘位互换后，再次开机会不会影响原先存储数据的完整性，是否会导致数据灾难？

[回答]
这个要取决于RAID控制器的固件设计，一个最重要的根本是，RAID信息(RAID元数据)记录在什么地方？可以记录RAID信息的地方只能有RAID控制器上的存储单元和硬盘上。

如果RAID信息只记录在控制器上，那么配置好的RAID里硬盘盘位互换后，数据一定会受到影响。这种记录方式使用较少，目前只有部分低端控制器采用。

RAID信息只记录在硬盘上的情况也不多见，如果RAID信息只记录在硬盘上，控制器便不具备记录RAID配置的能力，完全依赖于硬盘，安全性也较低。如果是这种情况，更换RAID盘位并不会导致数据灾难。

目前大多数控制器的实现是将RAID信息同时记录在控制器与硬盘上，这样，当两者中有一出故障，可通过另一份COPY还原。同时，可对RAID信息的正确性进行校验，通过控制器上存储的RAID信息为主信息，当RAID里的信息与硬盘里的信息不相同时，需要手工进行判断处理（比如强制上线）。此类情况更换硬盘盘位后，要么自动调整过来，不影响数据，要么需要手工确认一下。只要正确操作，便不会有数据灾难。

但必须指出的是，更换RAID盘位的操作还是相当危险的，安全级别越高的RAID控制器越敏感，更换盘位导致的一点点接口松动都有可能导致硬盘下线，从而影响整个RAID卷。更换RAID盘位操作，仅仅适用于迁移到另外的服务器或磁盘阵列控制下，但迁移之前，尽可能还是要完整备份数据，以防意外。

[数据恢复答疑]IBM 的RAID5E和RAID5EE适合我吗？

版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
[关键字] RAID数据恢复 数据恢复 磁盘阵列故障

[问题]
IBM的很多服务器有两种特殊的RAID结构，RAID5E与RAID5EE，这两种RAID结构有什么优点，从专业的RAID数据恢复角度看，这两种结构是否值得推荐？

[回答](北亚数据恢复中心张宇,http://www.datahf.net)

先转贴一段关于RAID5E与RAID5EE的介绍：
RAID5E & RAID5EE
RAID5E和RAID5EE是被经常提起的支持两个磁盘故障的技术，IBM的存储系统就是广泛采用这种RAID技术来实现双磁盘容错。它到底是如何实现，包含什么样的功能？
图－1 RAID5E
RAID5E，是在RAID5中每个 Extent (它是在IBM主机中用于创建RAID的单位) 的后面加入了热备用空间 (Hot Space，如图－1中Extent尾部的HS0、HSr、HSp等) 。如Extent0故障，那么其他剩余Extents的热备份空间将会被用来重建和重新分配数据，并保证剩下的Extents为RAID5的一部分。从而使得即使一个Extent故障，也能马上有热备用磁盘来替换它，并重建RAID5，从而又带来容错力；从而达到所说的支持两个磁盘故障。
但是，它所能容忍的并不是任何两个磁盘同一时刻故障，可以将它看作是RAID5和在线热备用磁盘(online hot spare drives)的变体。它将I/O操作时的数据分布到所有磁盘，包括热备用磁盘；从而减少了每个磁盘的带宽，带来更高的效率。然而，这也就意味着热备用磁盘不能够被多个阵列共享。
在RAID5E中，没有专用的热备用磁盘，就像RAID5中没有专门的校验磁盘一样，热备用数据块是分布到所有的磁盘中；从而，对于10个磁盘的RAID5E，每个磁盘的80%被用于存储数据，10%用于存储校验，10%用于热备用。
图－2 RAID5EE
此外，RAID5EE和RAID5E类似，只是热备用空间被分布在各个Extents中，就像RAID5的检验数据那样分散布置一样；如过某个Extent故障，那么剩余Extent中的热备用空间(如图-2中的HS0, HS1, HS2等)，将会被立即用于重建数据，并保证它成为原来RAID5的一部分，从而达到所说的支持两个磁盘故障。
同RAID5E相比，它不是把热备用空间放到每个Extent的尾部，而是分布在数据块其中，它也不允许任何两个磁盘同一时刻故障。不过，RAID5EE在进行热替换时，其寻址可能会更加方便和灵活。

以下是我对这两种结构的看法：
RAID5E与RAID5EE实际上是优化了的RAID5+HOT SPARE，其目的是让多余出来的热备盘同样参与RAID组，实现在一条RAID总线上更快地并行IO。
从RAID5E与RAID5EE的构建方式上看，除了可以提供稍快的读写IO外，其他优点并不明显，很多资料上说可以实现更快的重建速度，其实在RAID5E或RAID5EE降级时，控制器要用很复杂的算法(相对而言)，实现在线更改RAID级别(由RAID5E或RAID5EE变更为变种的RAID5)。同时，因RAID级别的变更，RAID组里的所有的硬盘都要进行全面读写。而再加入新的盘时，同样又要通过复杂的算法将RAID5变更回原来的RAID结构。所以在我们接触的好多RAID5E或RAID5EE案例中，客户都是没做任何操作，但数据却被破坏了，当然这有可能是控制器固件的故障，但不可否认的是，这种复杂的操作，高负载的IO也是根源之一。
所以，在IO性能并无特别要求的情况下(RAID5E与RAID5EE的性能提升也并不明显)，建议尽可能少用RAID5E或RAID5EE。

ORACLE数据块转储及RDBA的转换

转自：http://space.zdnet.com.cn/html/80/289380-1442131.html

很多时候我们在进行进一步研究时需要转储(dump)Oracle的数据块,以研究其内容,Oracle提供了很好的方式,我们通过以下例子简单说明一下:



[oracle@jumper udump]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.3.0 - Production on Tue Aug 31 17:01:27 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production
SQL> select rowid,deptno,dname,loc from scott.dept;
ROWID DEPTNO DNAME LOC
------------------ ---------- -------------- -------------
AAADZ7AABAAAGK6AAA 10 ACCOUNTING NEW YORK
AAADZ7AABAAAGK6AAB 20 RESEARCH DALLAS
AAADZ7AABAAAGK6AAC 30 SALES CHICAGO
AAADZ7AABAAAGK6AAD 40 OPERATIONS BOSTON
SQL> select file_id,block_id,blocks from dba_extents where segment_name='DEPT';
FILE_ID BLOCK_ID BLOCKS
---------- ---------- ----------
1 25273 8
SQL>alter system dump datafile 1 block min 25273 block max 25274;System altered.
SQL> !
[oracle@jumper udump]$ ls -l
total 4
-rw-r----- 1 oracle dba 3142 Aug 31 17:04 hsjf_ora_13674.trc
[oracle@jumper udump]$ more hsjf_ora_13674.trc
/opt/oracle/admin/hsjf/udump/hsjf_ora_13674.trc
Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production
ORACLE_HOME = /opt/oracle/product/9.2.0
System name: Linux
Node name: jumper.hurray.com.cn
Release: 2.4.18-14
Version: #1 Wed Sep 4 13:35:50 EDT 2002
Machine: i686
Instance name: hsjf
Redo thread mounted by this instance: 1
Oracle process number: 9
Unix process pid: 13674, image: oracle@jumper.hurray.com.cn (TNS V1-V3)
*** 2004-08-31 17:04:27.820
*** SESSION ID:(8.3523) 2004-08-31 17:04:27.819
Start dump data blocks tsn: 0 file#: 1 minblk 25273 maxblk 25274
buffer tsn: 0rdba: 0x004062b9 (1/25273)scn: 0x0000.0057c70d seq: 0x01 flg: 0x04 tail: 0xc70d1001
frmt: 0x02 chkval: 0x12e3 type: 0x10=DATA SEGMENT HEADER - UNLIMITED
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 1 #blocks: 7
last map 0x00000000 #maps: 0 offset: 4128
Highwater:: 0x004062bb ext#: 0 blk#: 1 ext size: 7
#blocks in seg. hdr's freelists: 1
#blocks below: 1
mapblk 0x00000000 offset: 0
Unlocked
Map Header:: next 0x00000000 #extents: 1 obj#: 13947 flag: 0x40000000
Extent Map
-----------------------------------------------------------------
0x004062ba length: 7

nfl = 1, nfb = 1 typ = 1 nxf = 0 ccnt = 1
SEG LST:: flg: USED lhd: 0x004062ba ltl: 0x004062ba
buffer tsn: 0rdba: 0x004062ba (1/25274)scn: 0x0000.0131909b seq: 0x07 flg: 0x04 tail: 0x909b0607
frmt: 0x02 chkval: 0xa8e7 type: 0x06=trans data
Block header dump: 0x004062ba
Object id on Block? Y
seg/obj: 0x367b csc: 0x00.131909a itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0001.02a.000003f3 0x0080000b.0188.08 C--- 0 scn 0x0000.0057c70e
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

data_block_dump,data header at 0xadb505c
===============
tsiz: 0x1fa0
hsiz: 0x1a
pbl: 0x0adb505c
bdba: 0x004062ba
76543210
flag=--------
ntab=1
nrow=4
frre=-1
fsbo=0x1a
fseo=0x1f44
avsp=0x1f2a
tosp=0x1f2a
0xe:pti[0] nrow=4 ffs=0
0x12:pri[0] ffs=0x1f86
0x14:pri[1] ffs=0x1f70
0x16:pri[2] ffs=0x1f5c
0x18:pri[3] ffs=0x1f44
block_row_dump:
tab 0, row 0, @0x1f86
tl: 26 fb: --H-FL-- lb: 0x0 cc: 3
col 0: [ 2] c1 0b
col 1: [10] 41 43 43 4f 55 4e 54 49 4e 47
col 2: [ 8] 4e 45 57 20 59 4f 52 4b
tab 0, row 1, @0x1f70
tl: 22 fb: --H-FL-- lb: 0x0 cc: 3
col 0: [ 2] c1 15
col 1: [ 8] 52 45 53 45 41 52 43 48
col 2: [ 6] 44 41 4c 4c 41 53
tab 0, row 2, @0x1f5c
tl: 20 fb: --H-FL-- lb: 0x0 cc: 3
col 0: [ 2] c1 1f
col 1: [ 5] 53 41 4c 45 53
col 2: [ 7] 43 48 49 43 41 47 4f
tab 0, row 3, @0x1f44
tl: 24 fb: --H-FL-- lb: 0x0 cc: 3
col 0: [ 2] c1 29
col 1: [10] 4f 50 45 52 41 54 49 4f 4e 53
col 2: [ 6] 42 4f 53 54 4f 4e
end_of_block_dump
End dump data blocks tsn: 0 file#: 1 minblk 25273 maxblk 25274

很多人经常提出的一个问题是,rdba是如何转换的?
rdba: 0x004062ba (1/25274)
我们通过这个例子介绍一下.
rdba从Oracle6->Oracle7->Oracle8发生了三次改变:
在Oracle6中,rdba由6位2进制数表示,也就是说数据块最多只能有2^6=64个数据文件(去掉全0和全1, 实际上最多只能代表62个文件)
在Oracle7中,rdba中的文件号增加为10位,为了向后兼容,从Block号的高位拿出4位作为文件号的高位.这样从6->7的Rowid无需发生变化.
而数据文件的个数理论上则扩展到了1022个(去掉全0和全1),在Oracle7中,rowid格式为:BBBBBBBB.RRRR.FFFF
在Oracle8中,文件号仍然用10位表示,只是不再需要置换,为了向后兼容,同时引入了相对文件号(rfile#),所以从Oracle7到Oracle8,Rowid仍然无需发生变化.
在Oracle8i中,Oracle引入了dataobj#,rowid的格式变为:OOOOOOFFFBBBBBBSSS,Oracle通过dataobj#进一步向上定为表空间等,从而使每个表空间
的数据文件数量理论上可以达到1022个
举例说明如下:
在Oracle6中:
比如: file 8, block 56892
26位block号==56892
vv vvvvvvvv vvvvvvvv vvvvvvvv
00100000 00000000 11011110 00111100
^^^^^^
6位文件号==8
在Oracle7中:
比如:File 255, block 56892
11111100 11000000 11011110 00111100
F C C 0 D E 3 C
\_____/\___/\_______________________/
| | |
| | Block = 0xDE3C = 56892
\_____________
| \
V V
0011 111111 = 0xFF = 255 --注意这里高位和低位要置换才能得出正确的file#
在Oracle8中:
比如:File 255, block 56892
11111100 11000000 11011110 00111100
F C C 0 D E 3 C
\_____/\___/\_______________________/
| | |
| | Block = 0xDE3C = 56892
\_____________
| \
V V
0011 1111 0011 = 03F3 = 1011 --这就是相对文件号
对于我们测试中的例子:
rdba: 0x004062ba (1/25274)
也就是:0000 0000 0100 0000 0110 0010 1011 1010
前10位为rfile#: 0000 0000 01 = 1
后22位为Block#:00 0000 0110 0010 1011 1010 = 25274
本文出自 51CTO.COM技术博客

[数据恢复答疑]RAID损坏后，我们该如何紧急应对？

版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
[关键字] RAID数据恢复 数据恢复 磁盘阵列故障

[问题]
RAID因硬盘离线，或其他原因导致不能工作时，在数据恢复服务之前，应该如果紧急应对，避免数据风险？

[回答](北亚数据恢复中心张宇,http://www.datahf.net)
RAID离线的原因见“[数据恢复答疑]RAID真的安全吗？”一文，既然RAID的损坏有时候是不可避免的，那出现问题后，该如果做紧急应对对于每个存储管理员而言是至关重要的。
通常出现此类问题后，需要：
1、不可频繁开机，试图激活RAID。
2、不可进入RAID管理程序，随意进行强制上线、重建(REBUILD)、初始化等操作。
3、不可随意重新拔插硬盘，试图激活RAID。
4、出现阵列故障开机后，发现RAID里所有硬盘或大多数硬盘读写指示灯忙灯，且有异于平常，需要尽快断电，不可再贸然开机。
5、尽可能断电后，将所有硬盘按原盘次序标号，然后参考“RAID损坏后 对数据的完整备份”一文进行安全备份。
6、寻求专业数据恢复机构帮助(广告一下：比如我公司，北亚数据恢复中心，http://www.datahf.net)

[数据恢复答疑]不同的RAID方案都适合于什么环境？

版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
[数据恢复问题]
RAID有不同的组织方案，有JBOD，RAID0，RAID1，RAID5，RAID6，RAID10，RAID01，ADG等，这些方案都适用于什么环境？

[回答](北亚数据恢复中心张宇,http://www.datahf.net)
RAID要解决的问题主要有3个:容量合并、IO性能、存储安全
JBOD是低端的RAID结构，有时候等同于WINDOWS的跨区卷，是将1块或几块硬盘首尾相接连起来的结构，只为解决硬盘扩容问题，安全性头差，IO性能与单盘无异，适用于安全级别与IO性能不高的容量组合环境。可以由任意多块硬盘组成。
RAID0实现容量合并，IO性能提高的目的，尤其IO性能是RAID0的主要特点，但安全性极差，比单盘还容易损坏，且设计成本很低，适合需要快速IO、容量大、但数据并不重要的环境。比如中转性的数据服务器，流媒体点播系统、或要求不高的监控系统。可以由任意多块硬盘组成。
RAID1安全突出存储安全，提供了所有RAID级别中最高的安全系数，当然也浪费了空间，增加了成本，同时IO性能并无明显提升，适合数据量不大，但极其重要的使用环境。通常只适合两块盘。
RAID5是一种中和的RAID结构，可以提供大容量空间，同时如果控制器性能足够好，可以提供高于单盘的IO性能(尤其是读性能)，同时提供允许一块硬盘损坏的安全保护，因多方面因素均有考虑，所以使用较广，缺点是最小需要3块硬盘组成，同时RAID5的算法复杂，需要有强劲的处理单元与高速缓冲才能更好的发挥RAID5的作用，导致成本很高。低端的RAID5实际上可能更容易出问题，性能不如单盘。适用于一般型企业的大多数存储要求。可多块硬盘构建。
RAID10与RAID01是结合RAID0与RAID1的一种结构，通常建议做RAID10（见以一起数据灾难谈RAID0+1及RAID1+0），标准的RAID10适合4块以上的偶数块硬盘组建，安全如RAID1,速度如RAID0，但会浪费50%的磁盘空间，处理器设计也较为简单，大型企业数据存储，如空间要求不大，RAID10是首选。
RAID6与ADG是RAID5的升级结构，支持两块硬盘同时离线，使得安全性更高，但算法过于复杂，导致IO读写命中率很低，IO性能很低，即使有高速的处理器与高速缓冲，仍然不见得是最好的组织结构，造价又很高，通常使用很少。但如果硬盘很多，数据量很大，RAID5的安全级别又不够高，RAID10又浪费太多，RAID6或ADG是最适合的了。

[数据恢复答疑]RAID5有一块硬盘离线后，为什么不建议马上做REBUILD？

版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
[数据恢复问题]
RAID5当一块硬盘离线后，处理降级状态，这时候正常的建议是马上更换硬盘做REBUILD以恢复完整的数据状态，如果有热备盘的话，就会自动做REBUILD，这样做合适吗？

[回答](北亚数据恢复中心张宇,http://www.datahf.net)
一组RAID卷在工作很长时间以后也很少会读到物理硬盘的所有磁盘空间，同一时间更是不可能。部分情况下，硬盘会在没有读到的区域或者以前读取是良好的区域产生坏道，这类坏道因为没有读写过，所以在控制器看来是好的。产生这种坏磁道的最直接危害是在REBUILD过程中。当一块物理硬盘离线后，通常所有的技术人员及官方资料都会写尽快做REBUILD，但如果其他硬盘存在这类平常不知的坏磁道，REBUILD又都是对全盘做全面同步，就一定会读写到那些坏道，这时候REBUILD没完成，新盘无法上线，因旧盘里又发现了坏道，便会导致RAID又多出一些下线的硬盘，这样就可能会导致RAID出现故障，无法自行进行数据恢复了。
所以，当RAID处理降级状态时，如重要数据容量不大，建议先做备份，当然这种备份应该是异机的，不可备份至当前已降级的RAID中。
如果在REBUILD当中出现另外硬盘离线的情况导致RAID卷OFFLINE，切不可重建RAID，如确定后离线的硬盘，可通过强制上线恢复数据(有些控制器没有选项，就没办法了)，也可咨询数据恢复公司进行处理。

[数据恢复答疑]重建RAID会破坏数据吗？重建RAID可以恢复RAID数据吗？

版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
[问题]
当RAID损坏，出现数据丢失的情况下，能否通过重建RAID结构来恢复raid数据？
磁盘阵列环境出现的数据灾难中RAID信息丢失的情况占很大比例，很多工程师都有过这样的经历：按原来的RAID结构重建一下RAID，数据就恢复出来了。这种方式可行吗？

[回答](北亚数据恢复中心张宇,http://www.datahf.net)
RAID的重建大致有几种方式：只创建RAID信息(RAID元信息)、创建RAID时只重新生成校验(只做同步)、创建RAID时填充初始化。
如果重建的结构与原先的结构不相同（涉及控制器固件、RAID级别、块大小、校验方式、盘序），重建好的RAID LOGICAL DRIVER一定和原先是不一样的，这样贸然加载文件系统，会破坏文件系统结构，导致数据丢失。
以下假设重建的结构与原先的结构是相同的：
如果控制器的重建方法是只创建RAID信息，那要看之前的RAID结构是正常的还是降级的，如果是降过级的(已有硬盘下过线)，重建好后，因数据是由新数据与部分旧数据组合而成的，文件系统会破坏，且不可逆向恢复。如果之前的RAID结构是完好的，重建RAID不会影响数据，可以将原来的数据完全原样的恢复出来。
如果控制器的重建方法是创建RAID重新生成校验(即使是后台的)，和上面的情况相同，如果硬盘之前就有离线的，这样的重建会破坏数据的一致性。如果之前的RAID状态是ONLINE（GOOD）的，那么这样的重建不会影响数据。
如果控制器的重建方法是填充数据重建(通常是清0)，那无论如何都会破坏数据。
这样看来，当RAID损坏后重建RAID可以恢复数据的前提是：控制器的设计是不破坏数据的，而且之前的RAID状态是良好的，同时重建的结构和原先的要完全一致。除此之外的重建都有数据风险。
实际上，多数RAID损坏并不是从良好 一下子到瘫痪的，大多数会通过降级这一步，所以实际上强行重建文件系统无论如何都不是很好的做法，只是降级到瘫痪这段时间内如果数据写入不多，可能重建后修复文件系统只影星降级到瘫痪这段时间内做的改动。
早期很多基于SCSI的磁盘阵列都会在重建时至少清0前面部分扇区（比如1M,10M等）。目前基于LSI的SAS控制器市场占有率很高，其控制器在重建时往往不会清除数据，但会在后台重新同步数据，也是有风险的。

[数据恢复答疑]RAID真的安全吗？

版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
问题：
数据恢复既然是数据灾难的一种补救措施，那设计得绝对安全的RAID磁盘阵列系统也会出现数据灾难吗？为什么？在RAID数据恢复领域里常见的故障类型有哪些？

回答(北亚数据恢复中心张宇 http://www.datahf.net)：
RAID设计的初衷大约有3个原因：解决容量问题、解决IO性能问题与解决存储安全(冗余)问题。从数据恢复的角度看，我们暂不讨论容量与IO性能方面，仅讨论存储安全。
RAID中可以起到存储安全的组织方案常见的为RAID1、RAID5及其变形，基本设计思路是相似的，都是能过一定的算法，用多块硬盘之间的算法维护来保证当部分数据异常时，可通过特定算法还原出来。拿RAID5的设计方式来看，举个简单的例子说明一下，如果我们要记录两个数字，那么可以通过再多记录他们的和来达到记录的冗余性，就像我们记录3和5，同时再记录一下8(为3+5的和)，那么如果我们不记得到底是几和5，只需要用8-5就可以算出这个丢失的数字了，其余情况依此。在磁盘阵列里同样是以某种算法来达到保全数据的目的，当一组3块盘的RAID5正常工作时，所有写入RAID里的数据都正确地写到特定磁盘地址，同时再生成一个特定的计算值(通常称为校验和)，这个时候的读写效率是最好的。但当其中一块盘出现故障时，存储在这块故障盘上的原有数据就要通过其他硬盘的数据恢复出来，当然这个过程中控制器(硬RAID为RAID卡，软RAID实际上是个驱动)会负责这个工作，同时为了保证不宕机，控制器也会保证存储的正常化，不会让操作系统认为硬盘系统出了问题。
从上面的原理来看，RAID提供的存储安全还有一些不太容易避免的漏洞，虽然可能性不大，但存储在RAID上的数据价值可能无法评估，出丝毫的故障都可能会导致一场大的信息灾难。
转入正题，RAID通常出现的故障可能性有：
1、处于降级状态时，未及时rebuild：RAID是通过多出来的部分存储空间来提供算法上的数据安全冗余的，但当某些盘出现故障下线后，RAID便不能再提供这种存储冗余，如果管理员不及时更换盘，REBUILD整个卷，这时候其余工作中的硬盘再出现故障，RAID卷便无法正常工作了。这类故障在RAID数据恢复中比例相当高，服务器维护管理跟不上很容易发生。

2、控制器故障：控制器是连接物理硬盘与操作系统之间的数据存储纽带，同时因RAID的组成方式并非自然约定(特定)，硬盘容量的大小，硬盘数量的多少，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就又是好硬盘了。但实际上，这类情况却是不可避免的，原因是：一组RAID卷在工作很长时间以后也很少会读到物理硬盘的所有磁盘空间，同一时间更是不可能。部分情况下，硬盘会在没有读到的区域或者以前读取是良好的区域产生坏道，这类坏道因为没有读写过，所以在控制器看来是好的。产生这种坏磁道的最直接危害是在REBUILD过程中。当一块物理硬盘离线后，通常所有的技术人员及官方资料都会写尽快做REBUILD，但如果其他硬盘存在这类平常不知的坏磁道，REBUILD又都是对全盘做全面同步，就一定会读写到那些坏道，这时候REBUILD没完成，新盘无法上线，因旧盘里又发现了坏道，便会导致RAID又多出一些下线的硬盘，这样就可能会导致RAID出现故障，无法自行进行数据恢复了。

7、人为误操作：涉及数据恢复的数据灾难有相当一部分也是可以避免的，但总会有这样的情况：无关人员误拔RAID里的硬盘、没准备备件盘、不及时换盘、给RAID除尘时忘了原来的顺序、不小心删除了原RAID配置等。

8、其他我暂时想不起来的原因。
这些灾难原因除人为原因外，大多数很难直接避免，只能通过结合备份，构建整体存储安全方案来解决。其他文章会提到原因，以及抛开数据恢复话题的安全建议。

[数据恢复解决]raid磁盘阵列OFFLINE后的数据恢复应急方案

[数据恢复对象]
IBM、HP、SUN、DELL、DFT、APPLE、联想、方正等服务器;
RAID0、RAID1、RAID2、RAID3、RAID4、RAID5、RAID6、HP ADG、RAID10、RAID50、RAID1E、RAID5E、RAID5EE等
NAS、DAS、SAN等
[数据恢复灾难症状]
1、RAID控制台里描述超过允许范围内的盘数异常，如RAID0里一块以上盘异常;RAID5(无热备)里2块以上盘异常;异常表现为OFFLINE或DDD、BAD等。
2、服务器存储系统报警（喇叭或警示灯）
3、系统无法识别RAID 逻辑硬盘

[应急处理]
1、迅速将RAID离线（如果还在线的话）,切断电源
2、如果发现非工作状态，硬盘灯全忙，应迅速关掉电源，不可再次开启电源。
3、RAID控制界面里不可轻易REBULD或初始化。
4、不可将原本离线的硬盘强制上线（陈旧的或无关的）
5、保持上述状态，关机后将每块硬盘贴上次序标签。
6、不可轻易将每块盘接到XP以下操作系统（含XP）。
7、寻求专业磁盘阵列数据恢复公司帮助。

[高级建议]
如果有足够的备用空间，可将源硬盘全部镜像。有两种方法（WINDOWS2003或DOS下，其他操作系统有风险）：
1、可用相同或大于源盘容量的硬盘做为目标盘，将源盘全部扇区方式CLONE到目标盘。将所有盘做同样操作。
2、可将每块源盘完全以扇区方式输出文件到某大容量存储空间（如大容量硬盘、NAS、SAN、DAS等）