背景：我使用 3x1tb 磁盘设置并运行 Ubuntu Bionic 系统。所有磁盘均分区为一个约 15GB 的分区，其余约 983GB。
由两个磁盘形成的 15GB 分区MD0，用于交换的 raid1 阵列。全部 3 个磁盘形成 983GB 分区MD10，用于 / 的 raid10 far 2 阵列，总计约 1.4tb。
发生了什么： 1 个硬盘出现故障。 raid10阵列无论如何都继续进行。 md0 要求我添加剩余未使用的 15GB 分区，但系统随后启动。不用担心\o/
接下来发生了什么：订购新驱动器几个小时后，文件系统变为只读，然后无法重新启动。本质上，第二个磁盘发生了故障，尽管 smart 报告了一系列 CRC 错误而不是坏块。
应该指出的是，在此之前我也遇到过 RAM 棒损坏的问题，以及与此同时发生的更换 RAM 的系统稳定性问题。 （现已解决。）
我现在在哪里：我使用 ddrescue 对两个磁盘进行了映像，并一直在检查并尝试使用 testdisk 修复文件系统。 （当前正在重新映像磁盘以重新开始）。本质上，当 ddrescue 复制时，一个磁盘看起来很好，另一个磁盘显示没有坏块或不可读扇区，但似乎存在文件系统问题。
我认为发生的情况是，不是第二个磁盘硬件发生故障，而是 RAM 损坏导致文件系统错误，导致该磁盘无法读取。
证据 mdadm --检查实际驱动器，sdf 为“好”，sdd 为“坏”：
/dev/sdf:
MBR Magic : aa55
Partition[0] : 31997952 sectors at 2048 (type fd)
Partition[1] : 1921523712 sectors at 32000000 (type fd)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 32002048 sectors at 2048 (type 83)
Partition[1] : 1921519616 sectors at 32004096 (type 83)
这里可以看到两件事，首先 sdd 分区已恢复为直接 ext4 linux(83) 而不是 linux raid (fd)，其次 sdd0 似乎从 sdd1 获得了 4096 个扇区（除非我以这种方式创建分区...但我怀疑这一点）。
Testdisk 似乎还首先确认文件系统问题良好的磁盘：
Disk /dev/sdf - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
Partition Start End Size in sectors
1 * Linux RAID 0 32 33 1991 231 32 31997952 [zen:0]
2 P Linux RAID 1991 231 33 121601 57 56 1921523712 [zen:10]
Disk /dev/sdd - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
Partition Start End Size in sectors
1 * Linux 0 32 33 1992 41 33 32002048
Bad relative sector.
2 P Linux 1992 41 34 121601 57 56 1921519616
我无法让 Testdisk 纠正这个问题 -partedmagic 上的版本似乎不支持 linux raid 分区，并且建议使用 fsck 导致超级块错误中的错误幻数，即使使用备用超级块也是如此。
以下是 mdadm --examine 作为循环设备安装的映像的结果，再次是好的 sdf，其次是坏的 sdd：
/dev/loop1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 152533db:4e587991:5e88fe61:7fc8bfb8
Name : zen:10
Creation Time : Wed Jun 20 10:47:05 2018
Raid Level : raid10
Raid Devices : 3
Avail Dev Size : 1921261568 (916.13 GiB 983.69 GB)
Array Size : 1440943104 (1374.19 GiB 1475.53 GB)
Used Dev Size : 1921257472 (916.13 GiB 983.68 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=4096 sectors
State : clean
Device UUID : ef11197c:7461dd9e:ad2e28f6:bad63a7b
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Aug 30 15:36:14 2018
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : 93267b2f - correct
Events : 55599
Layout : far=2
Chunk Size : 512K
Device Role : Active device 1
阵列状态：AA。 （'A' == 活动，'.' == 缺失，'R' == 替换）
/dev/loop2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 152533db:4e587991:5e88fe61:7fc8bfb8
Name : zen:10
Creation Time : Wed Jun 20 10:47:05 2018
Raid Level : raid10
Raid Devices : 3
Avail Dev Size : 1921257472 (916.13 GiB 983.68 GB)
Array Size : 1440943104 (1374.19 GiB 1475.53 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=0 sectors
State : active
Device UUID : f70177cb:7daea233:2feafe68:e36186cd
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Aug 30 15:25:37 2018
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : 3c6bebab - correct
Events : 55405
Layout : far=2
Chunk Size : 512K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing, 'R' == replacing)
再次值得注意的是 sdd1（又名 Loop2）有问题 - 没有列出“已用开发大小”。我尝试使用图像重新创建数组，虽然它似乎有效，但数组无法安装（再次出现坏的魔法超级块）。
问题 我认为 sdd 上损坏的分区映射是问题的根源，这看起来是对的吗？是否有可能解决这个问题，如果可以，用什么来解决？ fdisk？
期望的结果使阵列可安装，以便我可以将尽可能多的内容转储到不同的磁盘。我有 /etc 和 /home 的备份（理论上 - 还没有尝试恢复），但如果我可以暂时恢复这个阵列，这将很有帮助并且让我安心。短暂运行 photorec 表明大量文件也可以恢复，但在没有目录结构或文件名的情况下对近 TB 的文件进行排序...
[解决了] 我将制作的磁盘映像的新副本放在适当的位置，这样我之前的任何摆弄都不会弄乱事情。事实上，一个是分区映像，另一个是整个磁盘映像，因此安装它们：
losetup --show -f /recovered/imgs/sdf1-md10.img
losetup -o 16386097152 /dev/loop3 /media/adrian/855c7d84-25f0-4b2f-b8fa-a5408536aaff/sdd-801485.img
检查cat /proc/mdstat显示它们以 md127 的形式安装在非活动状态，所以我停止了它，然后按照 @derobert 的建议运行 assemble
mdadm --stop /dev/md127
mdadm -v --assemble --force /dev/md10 /dev/loop3 /dev/loop2
并且可以挂载和访问阵列！ \o/
在我自己的尝试开始时，我在研究中错过的重要事实是，如果您要在新系统上重新组装阵列，则需要指定设备 - 组装 - 甚至没有意识到这是可能的。
答案1
听起来您已经制作了副本并且只在副本上工作，这很好！
我认为，检查输出中缺少“Used Dev Size”不是问题。相反，我认为这意味着它正在使用整个设备。另一张显示已用大小比设备大小小 4096，这与一个分区小 4096 一致。 （当您创建阵列时，mdadm 使用所有设备的最小分区大小，否则无法构建阵列）。
我怀疑有什么东西损坏了你的分区表。对于您没有写入的扇区来说，被损坏但仍然看起来大部分有效的情况是非常罕见的。 83 作为 mdraid 的分区类型没有任何问题，其他类型实际上已经过时，不应该使用。非FS数据（da，如果我没记错的话）也是一个不错的选择。
我想你所需要的只是mdadm --assemble --force /dev/md«WHATEVER» /dev/loop1 /dev/loop2。您应该收到一条有关强制使用不是最新设备的消息，然后它应该组装阵列（降级）。然后，您可以尝试fsck.ext4（或无论哪种）/dev/md«WHATEVER»如果有效，您可能可以从系统的 initramfs 执行所有操作来恢复它，然后只需使用mdadm -a新磁盘并让它重建。