背景：我使用3x1tb磁盘安装并运行了Ubuntu Bionic系统。磁盘全部用一个大约15gb的分区和其余大约983gb的分区。
来自两个磁盘的15gb分区形成了md0，一个用于交换的raid1阵列。来自所有3个磁盘的983gb分区形成了md10，一个用于/的raid10 far 2阵列，总计约1.4tb。
发生了什么：一个硬盘驱动器发生故障。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（aka loop2）存在问题-未列出“ Used Dev Size”。我尝试过使用图像重新创建数组，尽管看起来可以正常工作，但该数组不可卸载（再次出现了坏的魔术超级块）。
问题看起来我是对的，认为这是问题的根源，它在sdd上的分区图已损坏？是否有可能解决此问题，如果可以的话，可以解决什么问题？fdisk？
所需的结果使该阵列可安装，因此我可以将其尽可能多地转储到另一个磁盘上。我有/ etc和/ home的备份（理论上-尚未尝试还原），但是如果可以暂时恢复该数组，这将很有帮助，请放心。简短的photorec运行表明很多文件的地狱也是可以恢复的，但是在几乎没有目录结构或文件名的情况下，对几乎是terrabyte的文件进行了排序...
[已解决]我将制作的磁盘映像的新副本放置到位，因此以前的所有摆弄都不会使事情搞砸。实际上，一个是分区映像，一个是整个磁盘映像，因此安装它们：
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的建议运行了汇编
mdadm --stop /dev/md127
mdadm -v --assemble --force /dev/md10 /dev/loop3 /dev/loop2
并可以安装和访问阵列！\ o /
我一开始就在研究中错过的重要事实是，如果要在新系统上重新组装阵列，则需要为--assemble指定设备-甚至都没有意识到。
听起来您已经制作了副本，但只能在副本上使用，那就太好了！
我认为检查输出中缺少“使用的开发规模”不是问题。相反，我认为这意味着它正在使用整个设备。另一个显示的已用大小比设备的大小小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磁盘，然后恢复新磁盘并对其进行重建。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句