首先介绍一下这个问题的背景：我在 QNAP TS869L 外部 RAID/NAS 系统内运行 RAID-6。我最初有 5 个 3 TB 的磁盘，后来又向 RAID 添加了 2 个 3 TB 的磁盘。QNAP 内部处理了增长和重新同步等，一切似乎都很好。
大约 2 周前，我的一个磁盘（磁盘 #5，同时磁盘 #2 也坏了）出现故障，不知何故（我不知道为什么），磁盘 1 和 2 也被踢出了阵列。我更换了磁盘 #5，但 RAID 并没有再次开始工作。
在给 QNAP 技术支持打了几次电话后，他们重新创建了阵列（使用 mdadm --create --force --assume-clean ...），但生成的阵列找不到文件系统，并且我被好心地介绍去联系一家我负担不起的数据恢复公司。
在查阅了一些旧日志文件、将磁盘重置为出厂默认设置等之后，我发现了这次重新创建过程中出现的一些错误 - 我希望我仍然保留一些原始元数据，但不幸的是我没有（我确实吸取了这个教训）。
我目前知道正确的块大小（64K）、元数据版本（1.0；出厂默认值为 0.9，但据我所知 0.9 不能处理超过 2 TB 的磁盘，我的是 3 TB），现在我找到了应该在磁盘上的 ext4 文件系统。
唯一需要确定的变量就是正确的磁盘顺序！
我开始使用在“创建新阵列后恢复 RAID 5 数据，而不是重新使用“但我对正确的 RAID-6 的顺序有点困惑。RAID-5 在很多地方都有很好的记录，但 RAID-6 则少得多。
另外，在阵列从 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 详细信息（基于我从旧日志文件重建的最佳猜测）
[~] # 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>
答案1
我建议使用与其他数组相同的顺序，因为它们很可能是在与所讨论的数组相同的条件下创建的。
记住在任何组装或创建时始终使用“--assume-clean” - 您可能非常了解这一点，但值得再次提及。
理想情况下，您实际上应该使用原始驱动器的映像 (dd)，而不是实际驱动器本身。我意识到事情并不总是理想的 :-)
最后，如果可以的话，“mount -o ro”只是为了获得另一个级别的“请不要写入驱动器”安全性:-)