Perc H740P：raid5 卷拆分为两个外部配置，无法导入

Question 1

好的，这就是我所做的。希望它能帮助下一个人。

事实调查

首先，我将所有磁盘连接到 HBA。GNU/Linux 尝试组装 raid，但确实发现（至少）两个 raid 卷（还有一些额外的卷）。然后我备份了每个磁盘的前 32MB 和后 32MB，并按其 WWID/WWN 进行索引。

然后我下载了 SNIA DDF 规范（https://www.snia.org/tech_activities/standards/curr_standards/ddf) 因为我知道 megaraid/dell (部分) 实现了它（ddf 锚块魔法并非de11de11偶然:)，然后编写了一个非常丑陋的脚本来解码数据并理解它。

这表明阵列实际上分为三种不同的配置，一种包含一个磁盘，另一种包含该磁盘和另外 4 个磁盘，还有一种包含剩下的 2 个磁盘。

如果不明白您在做什么，脚本本身就没什么用，所以我没有把它包括在这里。

最终，这让我能够确定磁盘的正确原始顺序。提示：创建阵列后，perccli /c0/s0 show all | grep WWN至少记下 WWN 的顺序（）和条带大小。

这个过程还给了我分区的起始偏移量（始终为 0）和大小（19531825152 个扇区）。

H740P（可能还有所有 megaraid 控制器）使用的 raid5 变体称为left-symmetric“带数据连续的 RAID-5 旋转奇偶校验 N（PRL=05、RLQ=03）”。

重新组装磁盘进行测试

然后我尝试使用测试重组 raid mdadm --build。不幸的是，mdadm 拒绝组装 raid5 阵列 - 你有写入数组并销毁数据:(

作为一种解决方法，为了测试顺序是否正确，我以快照模式启动了一个 kvm，使用一些随机的 GNU/Linux 启动映像和/dev/sdavirtio 磁盘作为磁盘：

exec kvmb -snapshot -m 16384 \
         -drive file=linux.img,snapshot=off \
         -drive file=/dev/sdm,if=virtio,snapshot=on \
         -drive file=/dev/sdl,if=virtio,snapshot=on \
         -drive file=/dev/sdk,if=virtio,snapshot=on \
         -drive file=/dev/sdi,if=virtio,snapshot=on \
         -drive file=/dev/sdg,if=virtio,snapshot=on \
         -drive file=/dev/sdf,if=virtio,snapshot=on \
         -drive file=/dev/sdh,if=virtio,snapshot=on

这使得磁盘按指定的顺序显示为/dev/vda，/dev/vdb等等，并允许我轻松测试各种选项。 VM 内部的第一次尝试成功：

mdadm --create /dev/md0 -f \
   --metadata 1.0 \
   --raid-devices 7 \
   -z $((19531825152/2))K -c 256K \
   -l raid5 -p ddf-N-continue \
   --assume-clean -k resync \
   /dev/vd?

对于 raid5，分区大小并不重要 - 如果它较大，则 GPT 分区表已损坏并且您有多余的数据，但磁盘的其余部分仍然可以读取。

我通过挂载分区（这不应该引发错误，但即使顺序错误也可能会成功）并使用来验证数据的正确性， btrfs scrub它会检查元数据和数据块的校验和，这是最终的测试，也是 btrfs 的一大优点。

然后我再次运行了 backzp。

然后，我按顺序记下了所有磁盘的 WWN，以便可以使用重新创建它perccli。我还备份了卷本身的第一个和最后一个 1GB 数据，以防 raid 控制器覆盖这些数据。

将卷移回 RAID 控制器

由于大约 14TB 的数据未备份（因为需要花费一些精力才能从其他地方检索到这些数据，而我又迫不及待地等待副本），因此进行完全恢复并不是我所期待的选项，因此我尝试将阵列移回控制器。

我的第一次尝试是将阵列格式化为包含 raid5 卷的 DDF 容器，使用与控制器相同的参数，但不幸的是，megaraid 控制器 - 虽然本身使用 DDF - 不支持“外部”DDF 导入，并且仅显示磁盘为“未配置良好”。

然后我尝试通过再次添加它来重新创建数组，例如：

perccli /c0 添加 vd r5 名称=XXX 驱动器=3,6,9,1,2,3,0 pdcache=off wb ra strip=256

在已启动的系统上使用 perccli 执行此操作可确保 RAID 控制器执行后台初始化，这不会造成破坏，并且对于 RAID5，即使磁盘顺序或条带大小错误也不会破坏数据，只要您使用确切地以任意顺序排列原始阵列中的所有磁盘，不要遗漏一个或给出太多。

这是我失败的地方——不知何故，我完全搞乱了磁盘的顺序，还损坏了卷的前 1.5MB。我完全不知道出了什么问题，但我尝试了很多排列，却没有看到正确的数据，以至于我以为 raid 控制器会以某种方式重新排序我的磁盘（但它没有，它完全按照指定的顺序进行排序）。

长话短说，我再次将磁盘连接到 HBA，并尝试但未能理解。这时我的原始备份就派上用场了：尽管我忘记了磁盘的顺序，但我仔细查看了备份，并通过查看十六进制转储将潜在顺序降低到两种可能的排列。创建阵列并mdadm测试数据让我找到了正确的顺序。

然后我再次记下 WWN 的顺序，将磁盘连接到控制器，启动并执行perccli /c0 add...。然后我恢复了卷的前 1.5MB（其中包括 GPT 分区和 LVM 标签，以及一些旧的剩余垃圾数据，这些数据在猜测顺序时非常有用）。在这种情况下，一定程度的信心能够撤消错误是有帮助的。

结果：阵列恢复，btrfs 一致，并且控制器现在正在后台初始化，这会使整个系统变慢几天，但这只是小小的代价。

学到的东西

我学到了很多东西！

perc 控制器（可能还有所有 megaraid 控制器）无法很好地应对频繁快速且间歇性的磁盘问题 - 我怀疑磁盘快速消失和返回触发了竞争条件，控制器试图将新配置写入磁盘，但只对某些磁盘成功执行了部分操作，最终将 raid 一分为二。这显然是一个固件错误。但谁会想到电源线会出现故障呢......
mdadm 对于理解或显示 DDF 标头没有多大帮助 - 我根本无法理解所显示的数据，而且我自己解码标头时发现，这是因为输出中缺少大量信息--detail。--examine它在实验中也没有多大帮助，因为它拒绝进行非破坏性的只读汇编。
perc/megaraid 控制器内部使用 SNIA DDF 格式，这是一个可公开访问的规范，非常有用，尽管最后我在没有这些信息的情况下才弄清楚我需要什么。
能够仅从数据中猜测出 RAID 条带的正确顺序非常有用。剩余的垃圾和其他有助于此的数据也非常有用。从现在开始，我将考虑将“磁盘 1”、“磁盘 2”等写入 RAID 卷标头的“空白”区域（前 2MB 中有很长的 0 字节）。
很容易搞砸——设备名称、RAID 成员编号、WWN、插槽编号等都不同，这意味着需要管理大量数据，而且 WWN 很长，我的老眼光也不怎么好了。另外，我组织能力不强，过于自信 :/
使用带有数据的磁盘创建和删除阵列不会擦除数据，至少对于 RAID5 和使用后台初始化来说是这样。前台初始化几乎肯定会将磁盘清零。这意味着您可以根据需要多次创建和删除阵列，而不会冒数据丢失的风险，但有一个可能的例外：删除阵列有时需要强制选项，因为 RAID 控制器认为它由于有效的分区标签而处于“正在使用”状态。而这可能将 GPT 标签清零 - YMMV，并确保备份了前几兆字节以防万一。
Perc/megaraid 无法理解非 dell/megaraid DDF 容器。至少我还没找到如何让我的控制器接受 mdadm 创建的 DDF 容器。如果能够在 GNU/Linux 中格式化磁盘并将它们移回控制器，那将大有帮助，并且可以避免我这边数小时的痛苦。

概括

我恢复了所有内容，而无需从备份中恢复，但代价是几天缓慢的后台初始化时间。我在上面写下了我的解决方案，以防其中一些可能对处于类似情况的其他人有用。

Answer

好的，这就是我所做的。希望它能帮助下一个人。

事实调查

首先，我将所有磁盘连接到 HBA。GNU/Linux 尝试组装 raid，但确实发现（至少）两个 raid 卷（还有一些额外的卷）。然后我备份了每个磁盘的前 32MB 和后 32MB，并按其 WWID/WWN 进行索引。

然后我下载了 SNIA DDF 规范（https://www.snia.org/tech_activities/standards/curr_standards/ddf) 因为我知道 megaraid/dell (部分) 实现了它（ddf 锚块魔法并非de11de11偶然:)，然后编写了一个非常丑陋的脚本来解码数据并理解它。

这表明阵列实际上分为三种不同的配置，一种包含一个磁盘，另一种包含该磁盘和另外 4 个磁盘，还有一种包含剩下的 2 个磁盘。

如果不明白您在做什么，脚本本身就没什么用，所以我没有把它包括在这里。

最终，这让我能够确定磁盘的正确原始顺序。提示：创建阵列后，perccli /c0/s0 show all | grep WWN至少记下 WWN 的顺序（）和条带大小。

这个过程还给了我分区的起始偏移量（始终为 0）和大小（19531825152 个扇区）。

H740P（可能还有所有 megaraid 控制器）使用的 raid5 变体称为left-symmetric“带数据连续的 RAID-5 旋转奇偶校验 N（PRL=05、RLQ=03）”。

重新组装磁盘进行测试

然后我尝试使用测试重组 raid mdadm --build。不幸的是，mdadm 拒绝组装 raid5 阵列 - 你有写入数组并销毁数据:(

作为一种解决方法，为了测试顺序是否正确，我以快照模式启动了一个 kvm，使用一些随机的 GNU/Linux 启动映像和/dev/sdavirtio 磁盘作为磁盘：

exec kvmb -snapshot -m 16384 \
         -drive file=linux.img,snapshot=off \
         -drive file=/dev/sdm,if=virtio,snapshot=on \
         -drive file=/dev/sdl,if=virtio,snapshot=on \
         -drive file=/dev/sdk,if=virtio,snapshot=on \
         -drive file=/dev/sdi,if=virtio,snapshot=on \
         -drive file=/dev/sdg,if=virtio,snapshot=on \
         -drive file=/dev/sdf,if=virtio,snapshot=on \
         -drive file=/dev/sdh,if=virtio,snapshot=on

这使得磁盘按指定的顺序显示为/dev/vda，/dev/vdb等等，并允许我轻松测试各种选项。 VM 内部的第一次尝试成功：

mdadm --create /dev/md0 -f \
   --metadata 1.0 \
   --raid-devices 7 \
   -z $((19531825152/2))K -c 256K \
   -l raid5 -p ddf-N-continue \
   --assume-clean -k resync \
   /dev/vd?

对于 raid5，分区大小并不重要 - 如果它较大，则 GPT 分区表已损坏并且您有多余的数据，但磁盘的其余部分仍然可以读取。

我通过挂载分区（这不应该引发错误，但即使顺序错误也可能会成功）并使用来验证数据的正确性， btrfs scrub它会检查元数据和数据块的校验和，这是最终的测试，也是 btrfs 的一大优点。

然后我再次运行了 backzp。

然后，我按顺序记下了所有磁盘的 WWN，以便可以使用重新创建它perccli。我还备份了卷本身的第一个和最后一个 1GB 数据，以防 raid 控制器覆盖这些数据。

将卷移回 RAID 控制器

由于大约 14TB 的数据未备份（因为需要花费一些精力才能从其他地方检索到这些数据，而我又迫不及待地等待副本），因此进行完全恢复并不是我所期待的选项，因此我尝试将阵列移回控制器。

我的第一次尝试是将阵列格式化为包含 raid5 卷的 DDF 容器，使用与控制器相同的参数，但不幸的是，megaraid 控制器 - 虽然本身使用 DDF - 不支持“外部”DDF 导入，并且仅显示磁盘为“未配置良好”。

然后我尝试通过再次添加它来重新创建数组，例如：

perccli /c0 添加 vd r5 名称=XXX 驱动器=3,6,9,1,2,3,0 pdcache=off wb ra strip=256

在已启动的系统上使用 perccli 执行此操作可确保 RAID 控制器执行后台初始化，这不会造成破坏，并且对于 RAID5，即使磁盘顺序或条带大小错误也不会破坏数据，只要您使用确切地以任意顺序排列原始阵列中的所有磁盘，不要遗漏一个或给出太多。

这是我失败的地方——不知何故，我完全搞乱了磁盘的顺序，还损坏了卷的前 1.5MB。我完全不知道出了什么问题，但我尝试了很多排列，却没有看到正确的数据，以至于我以为 raid 控制器会以某种方式重新排序我的磁盘（但它没有，它完全按照指定的顺序进行排序）。

长话短说，我再次将磁盘连接到 HBA，并尝试但未能理解。这时我的原始备份就派上用场了：尽管我忘记了磁盘的顺序，但我仔细查看了备份，并通过查看十六进制转储将潜在顺序降低到两种可能的排列。创建阵列并mdadm测试数据让我找到了正确的顺序。

然后我再次记下 WWN 的顺序，将磁盘连接到控制器，启动并执行perccli /c0 add...。然后我恢复了卷的前 1.5MB（其中包括 GPT 分区和 LVM 标签，以及一些旧的剩余垃圾数据，这些数据在猜测顺序时非常有用）。在这种情况下，一定程度的信心能够撤消错误是有帮助的。

结果：阵列恢复，btrfs 一致，并且控制器现在正在后台初始化，这会使整个系统变慢几天，但这只是小小的代价。

学到的东西

我学到了很多东西！

perc 控制器（可能还有所有 megaraid 控制器）无法很好地应对频繁快速且间歇性的磁盘问题 - 我怀疑磁盘快速消失和返回触发了竞争条件，控制器试图将新配置写入磁盘，但只对某些磁盘成功执行了部分操作，最终将 raid 一分为二。这显然是一个固件错误。但谁会想到电源线会出现故障呢......
mdadm 对于理解或显示 DDF 标头没有多大帮助 - 我根本无法理解所显示的数据，而且我自己解码标头时发现，这是因为输出中缺少大量信息--detail。--examine它在实验中也没有多大帮助，因为它拒绝进行非破坏性的只读汇编。
perc/megaraid 控制器内部使用 SNIA DDF 格式，这是一个可公开访问的规范，非常有用，尽管最后我在没有这些信息的情况下才弄清楚我需要什么。
能够仅从数据中猜测出 RAID 条带的正确顺序非常有用。剩余的垃圾和其他有助于此的数据也非常有用。从现在开始，我将考虑将“磁盘 1”、“磁盘 2”等写入 RAID 卷标头的“空白”区域（前 2MB 中有很长的 0 字节）。
很容易搞砸——设备名称、RAID 成员编号、WWN、插槽编号等都不同，这意味着需要管理大量数据，而且 WWN 很长，我的老眼光也不怎么好了。另外，我组织能力不强，过于自信 :/
使用带有数据的磁盘创建和删除阵列不会擦除数据，至少对于 RAID5 和使用后台初始化来说是这样。前台初始化几乎肯定会将磁盘清零。这意味着您可以根据需要多次创建和删除阵列，而不会冒数据丢失的风险，但有一个可能的例外：删除阵列有时需要强制选项，因为 RAID 控制器认为它由于有效的分区标签而处于“正在使用”状态。而这可能将 GPT 标签清零 - YMMV，并确保备份了前几兆字节以防万一。
Perc/megaraid 无法理解非 dell/megaraid DDF 容器。至少我还没找到如何让我的控制器接受 mdadm 创建的 DDF 容器。如果能够在 GNU/Linux 中格式化磁盘并将它们移回控制器，那将大有帮助，并且可以避免我这边数小时的痛苦。

概括

我恢复了所有内容，而无需从备份中恢复，但代价是几天缓慢的后台初始化时间。我在上面写下了我的解决方案，以防其中一些可能对处于类似情况的其他人有用。

Question 2

您可以尝试从已关闭的服务器上卸下所有驱动器，然后移除两个组，然后重新连接磁盘。这应该会将所有磁盘重置为“外部”状态。然后尝试通过一次操作将它们全部导入。

原则上，此控制器应使用 SNIA DDF 磁盘格式。HBA（不是 RAID 控制器）不会解释元数据，从而允许软件访问它。因此，如果您能够使用 HBA 将其连接到 Linux 机器，它可以使用其 MD RAID 检测和组装此阵列（Linux 除了可以理解自己的元数据外，还可以理解 DDF 和 IMSM 元数据），因此您至少可以访问其上的数据。例如，如果这些驱动器是 SATA，您只需将它们连接到主板即可。

为了以防万一，我会将所有使用 HBA 的磁盘转储到某个备份存储中。以防万一出现问题。

更新：看到你的进步，我可以提出进一步的建议。

您可以尝试使用十六进制编辑器调整元数据。可能需要手动将它们设置为相同的 UUID。

另一个想法是使用重新创建数组mdadm --assume-clean，它仅写入元数据并组装一个数组，但跳过将组件归零。

首先，猜测正确的顺序和布局；这可以从当前元数据中推断出来。
按照说明构建覆盖层在 wiki 中，这将给予你无限次尝试
成功后，在驱动器上重复成功的组装，而不是覆盖设备

另外，在重新组装之前，我会拿另一组驱动器（不含有价值的数据），模拟（尝试重复）它们的问题，然后按照这些说明先尝试修复它们。

Answer

您可以尝试从已关闭的服务器上卸下所有驱动器，然后移除两个组，然后重新连接磁盘。这应该会将所有磁盘重置为“外部”状态。然后尝试通过一次操作将它们全部导入。

原则上，此控制器应使用 SNIA DDF 磁盘格式。HBA（不是 RAID 控制器）不会解释元数据，从而允许软件访问它。因此，如果您能够使用 HBA 将其连接到 Linux 机器，它可以使用其 MD RAID 检测和组装此阵列（Linux 除了可以理解自己的元数据外，还可以理解 DDF 和 IMSM 元数据），因此您至少可以访问其上的数据。例如，如果这些驱动器是 SATA，您只需将它们连接到主板即可。

为了以防万一，我会将所有使用 HBA 的磁盘转储到某个备份存储中。以防万一出现问题。

更新：看到你的进步，我可以提出进一步的建议。

您可以尝试使用十六进制编辑器调整元数据。可能需要手动将它们设置为相同的 UUID。

另一个想法是使用重新创建数组mdadm --assume-clean，它仅写入元数据并组装一个数组，但跳过将组件归零。

首先，猜测正确的顺序和布局；这可以从当前元数据中推断出来。
按照说明构建覆盖层在 wiki 中，这将给予你无限次尝试
成功后，在驱动器上重复成功的组装，而不是覆盖设备

另外，在重新组装之前，我会拿另一组驱动器（不含有价值的数据），模拟（尝试重复）它们的问题，然后按照这些说明先尝试修复它们。

Perc H740P：raid5 卷拆分为两个外部配置，无法导入

答案1

事实调查

重新组装磁盘进行测试

将卷移回 RAID 控制器

学到的东西

概括

答案2

相关内容