首先提出一个小问题：我在QNAP TS869L外部RAID / NAS系统中运行RAID-6。 我从5块3TB的磁盘开始，后来又增加了2块3TB的磁盘。 QNAP内部负责处理日益增长和重新同步等问题，看起来一切正常。
大约两个星期前，我有一个磁盘（磁盘＃5，磁盘＃2同时坏了）失败，不知何故（我不知道为什么），磁盘1和磁盘2被踢出arrays。 我更换了磁盘＃5，但RAID没有再次开始工作。
在QNAP技术支持部门的一些调用之后，他们重新创build了数组（使用mdadm –create –force –assume-clean …），但是由此产生的数组找不到文件系统，我很好意地提到联系我无法承受的数据恢复公司。
经过一些挖掘旧的日志文件，重置磁盘出厂默认等，我发现在这个重新创build过程中犯了一些错误 – 我希望我仍然有一些原始的元数据，但不幸的是我不（当然了解到这一点）。
我目前正处在我知道正确的块大小（64K），元数据版本（1.0;出厂默认值是0.9，但是从我读的0.9不能处理超过2TB的磁盘，我的是3TB） ，我现在发现应该在磁盘上的ext4文件系统。
只有确定的variables是正确的磁盘顺序！
我开始使用“ 在创build新arrays而不是重新使用之后恢复RAID 5数据 ”的答案＃4中的描述，但是对于适当的RAID-6的顺序应该有点困惑。 RAID-5在很多地方都有很好的logging，但是RAID-6要less得多。
此外，磁盘arrays（即奇偶校验和数据块的分布）是否在arrays从5个磁盘增加到7个磁盘之后发生了变化，还是以这种方式重新组织它们：原生7磁盘RAID -6会是？
谢谢
更多的mdadm输出可能会有所帮助：
mdadm版本：
[~] # mdadm --version mdadm - v2.6.3 - 20th August 2007 从数组中的某个磁盘获取mdadm详细信息：
[~] # mdadm --examine /dev/sda3 /dev/sda3: Magic : a92b4efc Version : 1.0 Feature Map : 0x0 Array UUID : 1c1614a5:e3be2fbb:4af01271:947fe3aa Name : 0 Creation Time : Tue Jun 10 10:27:58 2014 Raid Level : raid6 Raid Devices : 7 Used Dev Size : 5857395112 (2793.02 GiB 2998.99 GB) Array Size : 29286975360 (13965.12 GiB 14994.93 GB) Used Size : 5857395072 (2793.02 GiB 2998.99 GB) Super Offset : 5857395368 sectors State : clean Device UUID : 7c572d8f:20c12727:7e88c888:c2c357af Update Time : Tue Jun 10 13:01:06 2014 Checksum : d275c82d - correct Events : 7036 Chunk Size : 64K Array Slot : 0 (0, 1, failed, 3, failed, 5, 6) Array State : Uu_u_uu 2 failed
当前磁盘顺序中数组的mdadm详细信息（基于从旧日志文件重build的最佳猜测）
[~] # mdadm --detail /dev/md0 /dev/md0: Version : 01.00.03 Creation Time : Tue Jun 10 10:27:58 2014 Raid Level : raid6 Array Size : 14643487680 (13965.12 GiB 14994.93 GB) Used Dev Size : 2928697536 (2793.02 GiB 2998.99 GB) Raid Devices : 7 Total Devices : 5 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Jun 10 13:01:06 2014 State : clean, degraded Active Devices : 5 Working Devices : 5 Failed Devices : 0 Spare Devices : 0 Chunk Size : 64K Name : 0 UUID : 1c1614a5:e3be2fbb:4af01271:947fe3aa Events : 7036 Number Major Minor RaidDevice State 0 8 3 0 active sync /dev/sda3 1 8 19 1 active sync /dev/sdb3 2 0 0 2 removed 3 8 51 3 active sync /dev/sdd3 4 0 0 4 removed 5 8 99 5 active sync /dev/sdg3 6 8 83 6 active sync /dev/sdf3
从/ proc / mdstat输出（md8，md9和md13是内部使用的交换等RAID;我之后是md0）
[~] # more /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] md0 : active raid6 sdf3[6] sdg3[5] sdd3[3] sdb3[1] sda3[0] 14643487680 blocks super 1.0 level 6, 64k chunk, algorithm 2 [7/5] [UU_U_UU] md8 : active raid1 sdg2[2](S) sdf2[3](S) sdd2[4](S) sdc2[5](S) sdb2[6](S) sda2[1] sde2[0] 530048 blocks [2/2] [UU] md13 : active raid1 sdg4[3] sdf4[4] sde4[5] sdd4[6] sdc4[2] sdb4[1] sda4[0] 458880 blocks [8/7] [UUUUUUU_] bitmap: 21/57 pages [84KB], 4KB chunk md9 : active raid1 sdg1[6] sdf1[5] sde1[4] sdd1[3] sdc1[2] sda1[0] sdb1[1] 530048 blocks [8/7] [UUUUUUU_] bitmap: 37/65 pages [148KB], 4KB chunk unused devices: <none>
我build议使用与其他数组相同的顺序，因为它们很可能是在与所讨论的数组相同的条件下创build的。
请记住在任何组装或创build时总是“ – 干净” – 你可能已经知道这一点，但值得再提及。
理想情况下，你应该实际上是工作的原始驱动器的图像（DD），而不是实际的驱动器本身。 我意识到事情并不总是理想的:-)
最后，如果可以的话，“mount -o ro”，如果你可以为另一个级别的“不要写驱动器请安全”:-)