MDADM 超级块恢复

Question 1

哎呀！真是麻烦。让我们看看能不能帮你解决。首先回顾一下你的磁盘和分区表：

sda - no partition table
sdb - sdb1 [Linux] sdb2 [Linux extended] sdb5 [swap]
sdc - no partition table
sdd - no partition table
sde - no partition table

这些都没有标记fd Linux raid 自动检测，这是默认的
您没有使用分区来组织磁盘空间 [0]
您似乎已将整个磁盘格式化为 ext2/3和使用整个磁盘作为 raidset 的一部分

我认为最后一点就是您失败的地方。启动脚本可能认为您需要进行 fsck，对卷进行了健全性检查，并在此过程中清除了 MD 超级块。dumpe2fs 对于 RAID 集的卷部分，应该不会返回任何内容。

以我的 RAID 为例：

root@mark21:/tmp/etc/udev# fdisk -l /dev/sda

Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000ffc4

Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048  1240233983   620115968   fd  Linux raid autodetect

root@mark21:/tmp/etc/udev# dumpe2fs /dev/sda1
dumpe2fs 1.41.14 (22-Dec-2010)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sda
Couldn't find valid filesystem superblock.

您能够重新创建 RAID 集是非常幸运的，但这并不能改变您部署中的根本缺陷。这将再次发生。

我的建议是：

备份该 RAID 组上的所有内容
销毁阵列并从每个设备中删除 md 超级块（man mdadm）
将这些磁盘清零：dd if=/dev/zero of=/dev/sdX bs=1M count=100
在 sda、sdc、sdd 和 sdf 上创建占磁盘 99% 的分区 [0]
将这些分区标记为type fd（Linux 突袭 wiki）
永远不要用任何类型的文件系统格式化这些分区
创建新的 RAID 5：mdadm --create /dev/md0 -v -f -l 5 -n 4 /dev/sda1 /dev/sdc1 /dev/sdd1 /dev/sde1
在 /etc/mdadm.conf 中更新新的 UUID
从此过上幸福的生活

根据您的描述，我推测 sdb 是您的系统磁盘，这没问题。只需确保您不会在创建 raid 集时意外包含它即可。完成此操作后，您应该可以解决问题，并且不会再遇到此问题。

[0] 我曾经在 SATA 磁盘上遇到过一个非常严重的故障，它有很多坏块。使用供应商工具重建磁盘后。我曾经完全相同的磁盘组现在变得独一无二，坏驱动器现在比低级格式化开始之前少了几个块，这当然破坏了我的分区表并阻止驱动器重新加入 MD RAID 组。

硬盘通常有一个“空闲列表”，其中包含仅供偶尔使用的备份块。我的想法是，该列表肯定已经用完了，而且由于这不是企业磁盘，因此它没有采取安全措施并让我有机会将其送去进行数据恢复，而是决定截断我的数据并重新调整整个磁盘的大小。

因此，在创建 RAID 集时，我再也不会使用整个磁盘，而是在创建通常跨越整个磁盘的分区时使用 95-99% 的可用空间。这还为您在替换故障成员时提供了一些额外的灵活性。例如，并非所有 250 GB 磁盘都具有相同数量的可用块，因此如果您的可用块数量低于最大值，那么您可以使用几乎任何品牌的磁盘来替换故障成员。

Answer

哎呀！真是麻烦。让我们看看能不能帮你解决。首先回顾一下你的磁盘和分区表：

sda - no partition table
sdb - sdb1 [Linux] sdb2 [Linux extended] sdb5 [swap]
sdc - no partition table
sdd - no partition table
sde - no partition table

这些都没有标记fd Linux raid 自动检测，这是默认的
您没有使用分区来组织磁盘空间 [0]
您似乎已将整个磁盘格式化为 ext2/3和使用整个磁盘作为 raidset 的一部分

我认为最后一点就是您失败的地方。启动脚本可能认为您需要进行 fsck，对卷进行了健全性检查，并在此过程中清除了 MD 超级块。dumpe2fs 对于 RAID 集的卷部分，应该不会返回任何内容。

以我的 RAID 为例：

root@mark21:/tmp/etc/udev# fdisk -l /dev/sda

Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000ffc4

Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048  1240233983   620115968   fd  Linux raid autodetect

root@mark21:/tmp/etc/udev# dumpe2fs /dev/sda1
dumpe2fs 1.41.14 (22-Dec-2010)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sda
Couldn't find valid filesystem superblock.

您能够重新创建 RAID 集是非常幸运的，但这并不能改变您部署中的根本缺陷。这将再次发生。

我的建议是：

备份该 RAID 组上的所有内容
销毁阵列并从每个设备中删除 md 超级块（man mdadm）
将这些磁盘清零：dd if=/dev/zero of=/dev/sdX bs=1M count=100
在 sda、sdc、sdd 和 sdf 上创建占磁盘 99% 的分区 [0]
将这些分区标记为type fd（Linux 突袭 wiki）
永远不要用任何类型的文件系统格式化这些分区
创建新的 RAID 5：mdadm --create /dev/md0 -v -f -l 5 -n 4 /dev/sda1 /dev/sdc1 /dev/sdd1 /dev/sde1
在 /etc/mdadm.conf 中更新新的 UUID
从此过上幸福的生活

根据您的描述，我推测 sdb 是您的系统磁盘，这没问题。只需确保您不会在创建 raid 集时意外包含它即可。完成此操作后，您应该可以解决问题，并且不会再遇到此问题。

[0] 我曾经在 SATA 磁盘上遇到过一个非常严重的故障，它有很多坏块。使用供应商工具重建磁盘后。我曾经完全相同的磁盘组现在变得独一无二，坏驱动器现在比低级格式化开始之前少了几个块，这当然破坏了我的分区表并阻止驱动器重新加入 MD RAID 组。

硬盘通常有一个“空闲列表”，其中包含仅供偶尔使用的备份块。我的想法是，该列表肯定已经用完了，而且由于这不是企业磁盘，因此它没有采取安全措施并让我有机会将其送去进行数据恢复，而是决定截断我的数据并重新调整整个磁盘的大小。

因此，在创建 RAID 集时，我再也不会使用整个磁盘，而是在创建通常跨越整个磁盘的分区时使用 95-99% 的可用空间。这还为您在替换故障成员时提供了一些额外的灵活性。例如，并非所有 250 GB 磁盘都具有相同数量的可用块，因此如果您的可用块数量低于最大值，那么您可以使用几乎任何品牌的磁盘来替换故障成员。

Question 2

我之前遇到过同样的问题，但我没有记录下来（而且是一段时间前的事了）。

我记得一些关于使用e2fsck -b <superblockSector> /dev/sdX和尝试的事情备份超级块扇区

你也可以看看测试磁盘

Answer

我之前遇到过同样的问题，但我没有记录下来（而且是一段时间前的事了）。

我记得一些关于使用e2fsck -b <superblockSector> /dev/sdX和尝试的事情备份超级块扇区

你也可以看看测试磁盘

Question 3

距离你的帖子已经有一段时间了，但我还是要写下这些：

“mdadm：无法打开设备 /dev/sdb1：设备或资源繁忙”

值得检查一下

猫/proc/mdstat

我猜你的驱动器连接到一些 raid 例如 /dev/md126

如果是的话，停止突袭

mdadm——停止/dev/md125

然后尝试重新组装你的 raid /dev/md0

mdadm --assemble --verbose --update 摘要 /dev/md0 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3

但是：更重要的问题是：

请勿使用磁盘容量大于 1.5 TB 的 RAID 5！

不可恢复的误码率

这是驱动器在应用循环冗余校验 (CRC) 代码和多次重试后无法恢复数据的速率。企业级驱动器（SCSI、FC、SAS）的 UBE（不可恢复位错误）率通常指定为 10^15 分之 1 位，台式机级驱动器（IDE/ATA/PATA、SATA）的 UBE（不可恢复位错误）率通常指定为 10^14 分之 1 位。（因此每 ~1.7 TB）

因此，如果你的一个驱动器发生故障，则有约 55% 的可能性不会重建（对于 UBE 10^-14）祝你好运......

更多内容请见： http://www.raidtips.com/raid5-ure.aspx

Answer