Bob*_*Bob 15 linux raid xfs mount mdadm
第一次海报 - 如果我没有正确遵守礼仪，我深表歉意。
\n我有一个大约 200TB 的 RAID6 阵列，包含 30 个磁盘，但无法安装它 - 我只收到消息：
\nmount /dev/md125 /export/models\nmount:/dev/md125: can't read superblock\n如果我运行mdadm --detail它，它显示为干净的：
/dev/md125:\n Version : 1.2\n Creation Time : Wed Sep 13 15:09:40 2017\n Raid Level : raid6\n Array Size : 218789036032 (203.76 TiB 224.04 TB)\n Used Dev Size : 7813894144 (7.28 TiB 8.00 TB)\n Raid Devices : 30\n Total Devices : 30\n Persistence : Superblock is persistent\n\n Intent Bitmap : Internal\n\n Update Time : Fri May 20 23:54:52 2022\n State : clean\n Active Devices : 30\n Working Devices : 30\n Failed Devices : 0\n Spare Devices : 0\n\n Layout : left-symmetric\n Chunk Size : 512K\n\nConsistency Policy : bitmap\n\n Name : localhost.localdomain:SW-RAID6\n UUID : f9b65f55:5f257add:1140ccc0:46ca6c19\n Events : 1152436\n\n Number Major Minor RaidDevice State\n 0 8 1 0 active sync /dev/sda1\n 1 65 161 1 active sync /dev/sdaa1\n 2 65 177 2 active sync /dev/sdab1\n 3 65 193 3 active sync /dev/sdac1\n 4 65 209 4 active sync /dev/sdad1\n 5 8 17 5 active sync /dev/sdb1\n 6 8 33 6 active sync /dev/sdc1\n 7 8 49 7 active sync /dev/sdd1\n 8 8 65 8 active sync /dev/sde1\n 9 8 81 9 active sync /dev/sdf1\n 10 8 97 10 active sync /dev/sdg1\n 11 8 113 11 active sync /dev/sdh1\n 12 8 129 12 active sync /dev/sdi1\n 13 8 145 13 active sync /dev/sdj1\n 14 8 161 14 active sync /dev/sdk1\n 15 8 177 15 active sync /dev/sdl1\n 16 8 193 16 active sync /dev/sdm1\n 17 8 209 17 active sync /dev/sdn1\n 18 8 225 18 active sync /dev/sdo1\n 19 8 241 19 active sync /dev/sdp1\n 20 65 1 20 active sync /dev/sdq1\n 21 65 17 21 active sync /dev/sdr1\n 22 65 33 22 active sync /dev/sds1\n 23 65 49 23 active sync /dev/sdt1\n 24 65 65 24 active sync /dev/sdu1\n 25 65 81 25 active sync /dev/sdv1\n 26 65 97 26 active sync /dev/sdw1\n 27 65 113 27 active sync /dev/sdx1\n 28 65 129 28 active sync /dev/sdy1\n 29 65 145 29 active sync /dev/sdz1\ncat /proc/stat显示：
[root@knox ~]# cat /proc/mdstat\nPersonalities : [raid1] [raid6] [raid5] [raid4]\nmd125 : active raid6 sdo1[18] sdh1[11] sdad1[4] sdd1[7] sdb1[5] sdi1[12] sdt1[23] sdr1[21] sdp1[19] sdx1[27] sdg1[10] sdn1[17] sdm1[16] sdab1[2] sdu1[24] sdl1[15] sde1[8] sdf1[9] sdw1[26] sdc1[6] sdq1[20] sdy1[28] sds1[22] sdv1[25] sdac1[3] sdz1[29] sdaa1[1] sda1[0] sdj1[13] sdk1[14]\n 218789036032 blocks super 1.2 level 6, 512k chunk, algorithm 2 [30/30] [UUUUUUUUUUUUUUUUUUUUUUUUUUUUUU]\n bitmap: 0/59 pages [0KB], 65536KB chunk\n\nmd126 : active raid1 sdae3[0] sdaf2[1]\n 976832 blocks super 1.0 [2/2] [UU]\n bitmap: 0/1 pages [0KB], 65536KB chunk\n\nmd127 : active raid1 sdaf1[1] sdae1[0]\n 100554752 blocks super 1.2 [2/2] [UU]\n bitmap: 1/1 pages [4KB], 65536KB chunk\n\nunused devices: <none>\nExamine在各个设备上也显示为健康（我没有包含所有设备的结果，因为它会占用太多空间，但它们都与此相同）：
/dev/sda1:\n Magic : a92b4efc\n Version : 1.2\n Feature Map : 0x1\n Array UUID : f9b65f55:5f257add:1140ccc0:46ca6c19\n Name : localhost.localdomain:SW-RAID6\n Creation Time : Wed Sep 13 15:09:40 2017\n Raid Level : raid6\n Raid Devices : 30\n\n Avail Dev Size : 15627788288 sectors (7.28 TiB 8.00 TB)\n Array Size : 218789036032 KiB (203.76 TiB 224.04 TB)\n Data Offset : 262144 sectors\n Super Offset : 8 sectors\n Unused Space : before=262056 sectors, after=0 sectors\n State : clean\n Device UUID : 917e739e:36fa7cf6:c618d73c:43fb7dec\n\nInternal Bitmap : 8 sectors from superblock\n Update Time : Fri May 20 23:54:52 2022\n Bad Block Log : 512 entries available at offset 72 sectors\n Checksum : 2b5e9556 - correct\n Events : 1152436\n\n Layout : left-symmetric\n Chunk Size : 512K\n\n Device Role : Active device 0\n Array State : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)\ndmesg 中的相关条目显示：
\n[13297.001208] XFS (md125): Mounting V5 Filesystem\n[13297.008854] XFS (md125): Log inconsistent (didn't find previous header)\n[13297.008874] XFS (md125): failed to find log head\n[13297.008878] XFS (md125): log mount/recovery failed: error -5\n[13297.008934] XFS (md125): log mount failed\n其背景相当长且复杂，但简短的版本是，我尝试通过添加额外的磁盘来扩展阵列，但操作被中断。我最终通过将其重塑回原来的 30 个磁盘来重建阵列（这花了整整两周！），但现在它不想挂载。
\n不幸的是，它没有备份（我的意思是你在哪里备份 200TB？！？！）。这里不应该存放任何有价值的东西，但是，对于人类来说，一些重要的东西已经存放在那里。
\n我已经查看过，xfs_repair但不确定是否应该在 RAID 阵列 (md125) 或单个 sd* 设备上运行它。
谢谢
\n更新（这一切背后的历史）：
\n该设备是运行 CentOS 7 (3.10.0-1160.11.1.e17.x86_64) 的 SuperMicro 服务器，mdadm 版本为 4.1 \xe2\x80\x93 2018-10-01，具有 RAID6 配置中的 30 x 8TB 磁盘。它还在 2 个 RAID1 阵列 \xe2\x80\x93 上具有引导和根权限，而 RAID6 阵列仅用于数据。由于空间不足，我们决定向阵列添加更多驱动器（总共可容纳 45 个驱动器）。
\n由于阵列中的原始磁盘是 4kN 驱动器，并且提供的设备是 512e，因此需要使用 sg_format 重新格式化它们以进行转换（Western Digital 支持的过程）。我从一张磁盘开始进行测试。不幸的是，这个过程中途被中断，所以我重新启动它并完成，有点 \xe2\x80\x93 它确实将磁盘转换为 4096k，但它确实抛出了一两个 I/O 错误，但它们没有\xe2\x80\ x99t 似乎太令人担忧了，我想，如果出现问题，它会在接下来的几个步骤中出现。我\xe2\x80\x99ve发现了dmesg日志，这表明I/O错误比我想象的要多得多。
\n无论如何，由于 sg_format 似乎完成正常，我进入下一阶段，即使用以下命令对磁盘进行分区
\n parted -a optimal /dev/sd<x>\n (parted) mklabel msdos\n (parted) mkpart primary 2048s 100% (need to check that the start is correct)\n (parted) align-check optimal 1 (verify alignment of partition 1)\n (parted) set 1 raid on (set the FLAG to RAID)\n (parted) print\n然后我将新磁盘添加到阵列中：
\n mdadm --add /dev/md125 /dev/sd<x>\n并且顺利完成。
\n然后我继续增长数组：
\n mdadm --grow --raid-devices=31 --backup-file=/grow_md125.bak /dev/md125\n我用 cat /proc/mdstat 监控了这一点，它显示它正在重塑，但速度为 0K/秒，并且重塑没有\xe2\x80\x99t 从 0% 进展。
\n大约 12 小时后，由于重塑已经\xe2\x80\x99t 从 0% 进展，我研究了中止它的方法，例如 mdadm --stop /dev/md125 不起作用，所以我最终重新启动了服务器
\n服务器进入紧急模式。
\n我能够以 root 身份登录，但 RAID6 阵列陷入重塑状态。
\n然后我尝试了mdadm --assemble --update=revert-reshape --backup-file=/grow_md125.bak --verbose --uuid= f9b65f55:5f257add:1140ccc0:46ca6c19 /dev/md125一下，结果是：
mdadm: No super block found on /dev/sde (Expected magic a92b4efc, got <varying numbers>\n mdadm: No RAID super block on /dev/sde\n .\n .\n mdadm: /dev/sde1 is identified as a member of /dev/md125, slot 6\n .\n .\n mdadm: /dev/md125 has an active reshape - checking if critical section needs to be restored\n mdadm: No backup metadata on /grow_md125.back\n mdadm: Failed to find backup of critical section\n mdadm: Failed to restore critical section for reshape, sorry.\n我尝试了不同的变化，包括mdadm --assemble --invalid-backup --force一切都无济于事。
此时我还删除了可疑磁盘，但这没有任何区别。
\n但我最接近解决这个问题的是运行mdadm /dev/md125 --assemble --invalid-backup --backup-file=/grow_md125.bak --verbose /dev/sdc1 /dev/sdd1 ....... /dev/sdaf1，这会产生：
mdadm: /dev/sdaf1 is identified as a member of /dev/md125, slot 4.\n mdadm: /dev/md125 has an active reshape - checking if critical section needs to be restored\n mdadm: No backup metadata on /grow_md125.back\n mdadm: Failed to find backup of critical section\n mdadm: continuing without restoring backup\n mdadm: added /dev/sdac1 to /dev/md125 as 1\n .\n .\n .\n mdadm: failed to RUN_ARRAY /dev/md125: Invalid argument\ndmesg有以下信息：
md: md125 stopped.\n md/raid:md125: reshape_position too early for auto-recovery - aborting.\n md: pers->run() failed ...\n md: md125 stopped.\n由于上述所有原因，我从救援 CD 启动，并能够将其重新调整回原来的 30 个设备，并启动回本机安装（我确实必须从 fstab 中注释掉该阵列才能执行此操作）。
\nNik*_*nov 15
我想扩展上面的建议。
\n设置覆盖块设备非常值得，因此您尝试恢复文件系统时所做的任何更改都不会更改 RAID 上的任何内容，这将允许您重置所有内容并从头开始。因此，你会得到无限次的尝试，从而释放心理压力。
\n我使用 Qemu\'s qemu-nbd、Linux nbd.ko（网络块设备驱动程序）和 qcow2 覆盖文件来完成此操作。
modprobe nbd\nmount /dev/sdXXN /tmp/overlay\nqemu-img create -f qcow2 -b /dev/md125 -F raw /tmp/overlay/attempt1.qcow2\nqemu-nbd：qemu-nbd -c /dev/nbd0 /tmp/overlay/attempt1.qcow2\n现在你有了一个/dev/nbd0数组的“可写克隆”。您可以安全地写入此设备，任何更改都将写入/tmp/overlay/attempt1.qcow2. 因此，例如，当您尝试 @shodanshok\ 的建议时，请将其应用于/dev/nbd0.
qemu-nbd -d /dev/nbd0\nrm /tmp/overlay/attempt1.qcow2\n然后重复步骤 (2) 中的所有操作。或者，您可以在空间和设备允许的情况下创建尽可能多的覆盖/dev/nbdX（例如，我有 16 个）并并行工作。当然，它们都应该使用不同的覆盖图像。如果您碰巧在某些尝试中仅恢复部分数据，而在其他尝试中恢复其他部分数据，则此功能非常有用。
使用 XFS 文件系统的克隆时，请记住每个文件系统都应该具有不同的 UUID。
\n当（如果）找到正确的恢复路径时，可以将其重新应用到原始设备，“不可逆地恢复文件系统”，或者您可以租用一些空间，从覆盖 NBD 转储恢复的数据，重新创建 RAID 和文件系统并将其下载回来。
\n我知道，这很难，也很麻烦。这就是数据恢复组织在使用 RAID 时收取高额费用的原因。当您亲自尝试时，您会同意这些账单并不像乍一看那样虚高。
\n我再说一遍，30 个设备的 RAID6 很痛苦。最好有 3 个 RAID6 阵列，每个阵列有 10 个驱动器，然后使用分层 MD RAID 0 或 LVM 将它们条带在一起。这将使事情更易于管理，并且您的重塑/检查操作将不需要几周的时间即可完成。是的，您定期（至少每隔一个月）进行 RAID 一致性检查（清理），不是吗？
\n更新：评论中有有价值的信息，值得在这里添加。
\n我怀疑 Synology DSM 中是否提供 qemu 功能。但您可以将磁盘连接到装有 Linux 的普通 PC 上并继续。或者尝试从网络或 LiveUSB \xe2\x80\x94 启动 Synology，可以连接 30 个磁盘的 NAS 基本上是一台普通的 amd64 机架式计算机。\xe2\x80\x93
\n@Mark 建议另一种创建叠加层的方法：
\n\n\n@Bob，还有其他选项用于创建覆盖 \xe2\x80\x94 我使用了 USB 拇指驱动器以及https://raid.wiki.kernel.org/index.php/Recovering_a_damaging_RAID中的步骤
\n
好方法，它使用 Device Mapper 框架，很可能存在于 DSM 中！而且它可能比我的方法更快。它是dmsetup使用稀疏覆盖文件创建虚拟设备的命令。然而，由于 RAID 阵列本身在您的情况下看起来很干净，并且我们谈论的只是修复文件系统，因此我建议创建组装阵列 ( /dev/md125) 的覆盖，而不是单个阵列组件的覆盖。
sho*_*hok 10
日志
[13297.001208] XFS (md125): Mounting V5 Filesystem
[13297.008854] XFS (md125): Log inconsistent (didn't find previous header)
[13297.008874] XFS (md125): failed to find log head
[13297.008878] XFS (md125): log mount/recovery failed: error -5
[13297.008934] XFS (md125): log mount failed
让我认为中止的重塑“洗牌”了 LBA 编号，以便 XFS 找不到其意图日志。这可能意味着广泛的损坏，因此正如其他人已经说过的那样，请停在这里并联系专业的数据恢复服务。
如果这是不可能的，我会尝试最后一次尝试，忽略 XFS 日志，mount -o ro,norecovery /dev/md125 /export/models但在极不可能的情况下，如果它起作用，请准备好广泛的数据损坏。
同样，如果它存储了关键数据，请在执行任何操作之前联系数据恢复公司。
| 归档时间： |
|
| 查看次数： |
2487 次 |
| 最近记录： |