交换磁盘前的状态

Question 1

发生以下情况时，您有一个驱动器 (您正在更换的那个驱动器) 发生故障：

这时出现了一个奇怪的问题，parted 无法访问一个旧磁盘。我注意到另一个驱动器从阵列中消失了，几秒钟后又有一个驱动器消失了。阵列出现故障。我非常震惊，关闭了系统以防止进一步出现错误。

如果故障是致命的，则需要 3 次驱动器。

您说操作系统在 RAID 1 上，我假设那是 2 个磁盘，而其他 7 个磁盘在 RAID 6 上。

RAID 6 可以承受阵列中两个磁盘的丢失。如果 RAID 6 阵列中发生 3 次故障（假设所有故障磁盘均不属于 RAID 1），并且磁盘状态不佳，则数据很可能丢失。

您可以使用以下命令验证每个磁盘的状态：

sudo smartctl -a /dev/sdX

然后你就可以发现这 3 个磁盘是否都出来了或者是否只是侥幸。如果这只是一个意外，而且你确定一切都好，你的 mdadm.conf 和 fstab 是正确的，因为你的数组似乎是不活跃，那么你可以尝试使用（强制重新组装警告：危险，请阅读以下免责声明)：

sudo mdadm --stop /dev/md2
sudo mdadm --assemble --scan --force

注意：最后的--detail输出显示 6 个磁盘，而不是 7 个/dev/sdd。似乎丢失了。

您可以粘贴您的配置文件，文件系统以及 LVM VG、LV 和分区以帮助理解配置。

免责声明：尝试使用损坏的 RAID 进行操作非常危险，我根据您提供的可用信息推荐一些步骤，但我无法保证它会起作用或不会破坏您的数据。请自行承担责任和风险。

Answer

发生以下情况时，您有一个驱动器 (您正在更换的那个驱动器) 发生故障：

这时出现了一个奇怪的问题，parted 无法访问一个旧磁盘。我注意到另一个驱动器从阵列中消失了，几秒钟后又有一个驱动器消失了。阵列出现故障。我非常震惊，关闭了系统以防止进一步出现错误。

如果故障是致命的，则需要 3 次驱动器。

您说操作系统在 RAID 1 上，我假设那是 2 个磁盘，而其他 7 个磁盘在 RAID 6 上。

RAID 6 可以承受阵列中两个磁盘的丢失。如果 RAID 6 阵列中发生 3 次故障（假设所有故障磁盘均不属于 RAID 1），并且磁盘状态不佳，则数据很可能丢失。

您可以使用以下命令验证每个磁盘的状态：

sudo smartctl -a /dev/sdX

然后你就可以发现这 3 个磁盘是否都出来了或者是否只是侥幸。如果这只是一个意外，而且你确定一切都好，你的 mdadm.conf 和 fstab 是正确的，因为你的数组似乎是不活跃，那么你可以尝试使用（强制重新组装警告：危险，请阅读以下免责声明)：

sudo mdadm --stop /dev/md2
sudo mdadm --assemble --scan --force

注意：最后的--detail输出显示 6 个磁盘，而不是 7 个/dev/sdd。似乎丢失了。

您可以粘贴您的配置文件，文件系统以及 LVM VG、LV 和分区以帮助理解配置。

免责声明：尝试使用损坏的 RAID 进行操作非常危险，我根据您提供的可用信息推荐一些步骤，但我无法保证它会起作用或不会破坏您的数据。请自行承担责任和风险。

Question 2

mdadm 用于superblocks确定如何组装磁盘等。在这种情况下，查看物理驱动器的实际超级块数据总是非常有帮助和有用的前正在做任何行动写对磁盘进行某些操作（例如mdadm --assemble --scan --force，它将更新 mdadm 超级块）。

用于mdadm --examine /dev/sd<your-array-member-harddrives>查看超级块包含的内容。它应该可以让您了解发生故障时的情况、写入时磁盘之间的偏移量等等。

在清楚了解了是根据物理驱动器的当前状态，您可以制定策略来修复问题。

但首先，我还认为主板/sata 控制器/scsi 控制器/... 存在物理缺陷。如此多的磁盘在很短的时间内发生故障是不寻常的（除非有人想出了一个好主意，使用来自同一制造商的所有磁盘和生产批次来构建 raid 系统），这可能表明存在控制器问题。在最终发生故障的硬盘控制器上重建/重新同步损坏的 raid 只会导致灾难。

Answer

mdadm 用于superblocks确定如何组装磁盘等。在这种情况下，查看物理驱动器的实际超级块数据总是非常有帮助和有用的前正在做任何行动写对磁盘进行某些操作（例如mdadm --assemble --scan --force，它将更新 mdadm 超级块）。

用于mdadm --examine /dev/sd<your-array-member-harddrives>查看超级块包含的内容。它应该可以让您了解发生故障时的情况、写入时磁盘之间的偏移量等等。

在清楚了解了是根据物理驱动器的当前状态，您可以制定策略来修复问题。

但首先，我还认为主板/sata 控制器/scsi 控制器/... 存在物理缺陷。如此多的磁盘在很短的时间内发生故障是不寻常的（除非有人想出了一个好主意，使用来自同一制造商的所有磁盘和生产批次来构建 raid 系统），这可能表明存在控制器问题。在最终发生故障的硬盘控制器上重建/重新同步损坏的 raid 只会导致灾难。

Question 3

我仅提供一些关于如何/分析什么以了解当前状态的想法：

第一部分不是很有趣，并且对于所有数组成员来说都应该相同。

          Magic : a92b4efc               
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 607914eb:666e2a46:b2e43557:02cc2983
           Name : uranus:2  (local to host uranus)
  Creation Time : Thu Aug  6 00:45:41 2015
     Raid Level : raid6
   Raid Devices : 7

 Avail Dev Size : 7489544192 (3571.29 GiB 3834.65 GB)
     Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
  Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)

仍然不是很有趣，如果磁盘大小不相等，偏移量可能会有所不同。UUID 是硬盘 UUID，并且对于每个驱动器都是唯一的。

    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=11264 sectors
          State : active
    Device UUID : 49c6404e:ee9509ba:c980942a:1db9cf3c

Internal Bitmap : 8 sectors from superblock

这里开始变得有趣了，评论开头是#：

    Update Time : Fri Jul 13 22:34:48 2018   # last write activity on the drive
       Checksum : aae603a7 - correct   # should be equal on all disks, when the state is clean
         Events : 2739360   # Events on the disk, in bock/chunk units

         Layout : left-symmetric   # could be relevant for rebuilding the array, left-symmetric is default for x86
     Chunk Size : 512K

下一节对于重建数组很有趣，特别是在形成命令时，这一点Device Role很重要。

   Device Role : Active device 3
   Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing)

数组状态仅提供信息，但不会有太大帮助。

首先我们想了解一下How far have disks run apart during the failure?

50如果我没记错的话，在尝试时，mdadm 代码中有一个事件阈值assemble --force。这意味着，如果事件有差异，>50 assemble --force将不再起作用。尽管<50事件有差异也不能保证强制组装会起作用。在这种情况下，唯一的可能性是使用与现有参数完全相同的参数重新创建数组，并指示 mdadm --create --assume-clean。当一个人处于所有超级块都可用并且可以读取的“幸运”情况下时，这应该相当“容易”但要小心。

事件计数看起来像是第一个磁盘首先出局，然后是最后一个，然后是倒数第二个。不同之处在于<50，它最终可能会变得相当容易。

     Events : 2739360
     Events : 2739385
     Events : 2739385
     Events : 2739385
     Events : 2739381
     Events : 2739377

Array State只有关注Events计数 &才有可能正确地解释Drive Role。

Device Role : Active device 3
Device Role : Active device 0
Device Role : Active device 1
Device Role : Active device 4
Device Role : Active device 6
Device Role : Active device 5

Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.A ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..AAA ('A' == active, '.' == missing, 'R' == replacing)

mdadm从开始计数0。驱动器2首先发生故障，然后是驱动器3，然后是驱动器，5最后是驱动器6。请注意，驱动器5仍将驱动器列为6活动驱动器，驱动器也将和3列为活动驱动器。因此，当另一个驱动器发生故障时，很可能驱动器尚未更新超级块。356

在看到之后Array States，我确实认为自动操作assemble --force不会很好地发挥作用，因为上的 5 个设备之间没有一致性Array State。阵列有raid67 个磁盘，因此在这种情况下，我们需要有 5 个磁盘在上一致，Array State并且事件差异小于 50，但事实并非如此。

请记住，mdadm/ 的raid构建目的是不丢失数据。因此，代码中存在一些机制，可以防止mdadm可能损害数据的操作。即使使用 --force，自动重组也只会触发很可能成功的操作。如果超级块中没有足够/一致的信息供 mdadm 做出保存决定，它将失败。如果您真的知道自己在做什么，您可以简单地重写超级块以及create --assume-clean将 raid 重新投入运行所需的所有信息。但这将是一项手动任务，您作为管理员/用户必须指示软件具体要做什么。

我不会在这里提供复制和粘贴命令，因为我认为在这种情况下，在执行“repair-my-raid”命令之前，了解自己要做什么是至关重要的。为了加深知识，阅读 Linux RAID Wiki 上与 RAID Recovery 相关的整个文章是必不可少的，这是我对此答案的结论。

https://raid.wiki.kernel.org/index.php/Linux_Raid#When_Things_Go_Wrogn https://raid.wiki.kernel.org/index.php/RAID_Recovery https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID

Answer

我仅提供一些关于如何/分析什么以了解当前状态的想法：

第一部分不是很有趣，并且对于所有数组成员来说都应该相同。

          Magic : a92b4efc               
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 607914eb:666e2a46:b2e43557:02cc2983
           Name : uranus:2  (local to host uranus)
  Creation Time : Thu Aug  6 00:45:41 2015
     Raid Level : raid6
   Raid Devices : 7

 Avail Dev Size : 7489544192 (3571.29 GiB 3834.65 GB)
     Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
  Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)

仍然不是很有趣，如果磁盘大小不相等，偏移量可能会有所不同。UUID 是硬盘 UUID，并且对于每个驱动器都是唯一的。

    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=11264 sectors
          State : active
    Device UUID : 49c6404e:ee9509ba:c980942a:1db9cf3c

Internal Bitmap : 8 sectors from superblock

这里开始变得有趣了，评论开头是#：

    Update Time : Fri Jul 13 22:34:48 2018   # last write activity on the drive
       Checksum : aae603a7 - correct   # should be equal on all disks, when the state is clean
         Events : 2739360   # Events on the disk, in bock/chunk units

         Layout : left-symmetric   # could be relevant for rebuilding the array, left-symmetric is default for x86
     Chunk Size : 512K

下一节对于重建数组很有趣，特别是在形成命令时，这一点Device Role很重要。

   Device Role : Active device 3
   Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing)

数组状态仅提供信息，但不会有太大帮助。

首先我们想了解一下How far have disks run apart during the failure?

50如果我没记错的话，在尝试时，mdadm 代码中有一个事件阈值assemble --force。这意味着，如果事件有差异，>50 assemble --force将不再起作用。尽管<50事件有差异也不能保证强制组装会起作用。在这种情况下，唯一的可能性是使用与现有参数完全相同的参数重新创建数组，并指示 mdadm --create --assume-clean。当一个人处于所有超级块都可用并且可以读取的“幸运”情况下时，这应该相当“容易”但要小心。

事件计数看起来像是第一个磁盘首先出局，然后是最后一个，然后是倒数第二个。不同之处在于<50，它最终可能会变得相当容易。

     Events : 2739360
     Events : 2739385
     Events : 2739385
     Events : 2739385
     Events : 2739381
     Events : 2739377

Array State只有关注Events计数 &才有可能正确地解释Drive Role。

Device Role : Active device 3
Device Role : Active device 0
Device Role : Active device 1
Device Role : Active device 4
Device Role : Active device 6
Device Role : Active device 5

Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.A ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..AAA ('A' == active, '.' == missing, 'R' == replacing)

mdadm从开始计数0。驱动器2首先发生故障，然后是驱动器3，然后是驱动器，5最后是驱动器6。请注意，驱动器5仍将驱动器列为6活动驱动器，驱动器也将和3列为活动驱动器。因此，当另一个驱动器发生故障时，很可能驱动器尚未更新超级块。356

在看到之后Array States，我确实认为自动操作assemble --force不会很好地发挥作用，因为上的 5 个设备之间没有一致性Array State。阵列有raid67 个磁盘，因此在这种情况下，我们需要有 5 个磁盘在上一致，Array State并且事件差异小于 50，但事实并非如此。

请记住，mdadm/ 的raid构建目的是不丢失数据。因此，代码中存在一些机制，可以防止mdadm可能损害数据的操作。即使使用 --force，自动重组也只会触发很可能成功的操作。如果超级块中没有足够/一致的信息供 mdadm 做出保存决定，它将失败。如果您真的知道自己在做什么，您可以简单地重写超级块以及create --assume-clean将 raid 重新投入运行所需的所有信息。但这将是一项手动任务，您作为管理员/用户必须指示软件具体要做什么。

我不会在这里提供复制和粘贴命令，因为我认为在这种情况下，在执行“repair-my-raid”命令之前，了解自己要做什么是至关重要的。为了加深知识，阅读 Linux RAID Wiki 上与 RAID Recovery 相关的整个文章是必不可少的，这是我对此答案的结论。

https://raid.wiki.kernel.org/index.php/Linux_Raid#When_Things_Go_Wrogn https://raid.wiki.kernel.org/index.php/RAID_Recovery https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID

Question 4

1. Would you suggest first trying --assemble --force, maybe with an overlay file?

在我看来，这绝对是第一个值得尝试的选项。是否使用覆盖文件取决于您的数据和风险承受能力。到目前为止，我在这种情况下都有备份，因此没有使用覆盖选项。如果您想稳妥行事，请使用它。在这方面我想强调几点：

不要考虑使用 mdadm< 4.0版本。制作反向移植版或编译版本>= 4.0。中存在一些错误3.x，导致assemble --force与配合良好的操作失败4.0。
当尝试assemble --force使用时--verbose，它将为您提供一组很好的信息，这些信息有助于采取进一步的步骤并了解发生了什么或失败了什么。

2. If i use a --create --assume-clean, is it a better choice to create the last functioning setup with 6 disks or maybe a setup with only 5 drives that have the highest event count? The Is this even possible? My goal is restoring some important data from the array and no permanent solution.

在您的情况下，事件偏移量如此之小，我认为用 6/7 个磁盘重新创建阵列没有任何问题。如果您怀疑 HBA（sata/ide/scsi 控制器）可能有问题，最终应该考虑忽略可疑端口。但这取决于硬件和接线。是的，这是可能的，但取决于 raid 类型。使用 raid6，您可以尝试仅使用 5/7 个磁盘进行重建，从技术上讲，这样做应该没有任何限制。重要的是，如果您使用 5/7 重新创建它，驱动器肯定不会再发生故障。

3. I have details about the array before the crash occured. According to this i would come up with a mdadm --create --assume-clean --level=6 --raid-devices=7 --size=3744766464 /dev/sdb4 /dev/sdc4 missing /dev/sda1 /dev/sde4 /dev/sdg1 /dev/sdf1 for 6 drives, respectively mdadm --create --assume-clean --level=6 --raid-devices=7 --size=3744766464 /dev/sdb4 /dev/sdc4 missing missing /dev/sde4 /dev/sdg1 /dev/sdf1 on a 5 drive solution. Would you agree with this?

我还没有核实细节（驱动器顺序、大小、缺失位置等），但命令看起来不错。不过，正如 Linux Raid Wiki 上提到的那样，重新创建应该被视为最后的求助。当需要这样做时，我总是尽量做到尽可能具体。只需记住，我上次查看了 mdadm 手册页并添加了所有我知道数据的选项（例如，甚至是块大小、对齐方式等）。有很多默认值可以省略，但是当确定值时，为什么不具体一点呢。

针对您的情况，我会尝试以下方法：

调mdadm出一个版本>=4.0
停止阵列（如果正在运行）。检查/proc/mdstat并使用mdadm --stop ...。
验证磁盘和 HBA（sata/ide/scsi 控制器）。检查dmesg和smartctl记录。尝试从磁盘读取（例如。。dd if=/dev/hda1 of=/dev/null bs=1M count=2048重新检查dmesg和smartctl记录。重复此操作，添加一些ibs=和skip=。重新检查dmesg和记录。如果您在 HBA上smartctl看到任何内容，请停止使用该硬件的磁盘上的任何程序。resets|timeouts|failuresata|sata|scsi|...
在所有磁盘上重复验证磁盘和 HBA。
运行mdadm --assemble --scan --verbose。这很可能会失败，但它可以让您很好地了解 mdadm 发现了什么，并让您了解当您force这样做时会发生什么。
研究上述输出，检查您所看到的内容是否与您已经收集的有关驱动器/阵列的信息相符。
停止阵列（如果它正在运行或者已启动）。
如果您对 mdadm 的操作感到满意--assemble --scan --verbose，请尝试一下--force。
如果所有这些都失败了，请进行全盘备份（或创建覆盖文件），然后返回到最后的采取并重新创建整个阵列，使用assume-clean和从阵列收集的所有信息。

Answer

1. Would you suggest first trying --assemble --force, maybe with an overlay file?

在我看来，这绝对是第一个值得尝试的选项。是否使用覆盖文件取决于您的数据和风险承受能力。到目前为止，我在这种情况下都有备份，因此没有使用覆盖选项。如果您想稳妥行事，请使用它。在这方面我想强调几点：

不要考虑使用 mdadm< 4.0版本。制作反向移植版或编译版本>= 4.0。中存在一些错误3.x，导致assemble --force与配合良好的操作失败4.0。
当尝试assemble --force使用时--verbose，它将为您提供一组很好的信息，这些信息有助于采取进一步的步骤并了解发生了什么或失败了什么。

2. If i use a --create --assume-clean, is it a better choice to create the last functioning setup with 6 disks or maybe a setup with only 5 drives that have the highest event count? The Is this even possible? My goal is restoring some important data from the array and no permanent solution.

在您的情况下，事件偏移量如此之小，我认为用 6/7 个磁盘重新创建阵列没有任何问题。如果您怀疑 HBA（sata/ide/scsi 控制器）可能有问题，最终应该考虑忽略可疑端口。但这取决于硬件和接线。是的，这是可能的，但取决于 raid 类型。使用 raid6，您可以尝试仅使用 5/7 个磁盘进行重建，从技术上讲，这样做应该没有任何限制。重要的是，如果您使用 5/7 重新创建它，驱动器肯定不会再发生故障。

3. I have details about the array before the crash occured. According to this i would come up with a mdadm --create --assume-clean --level=6 --raid-devices=7 --size=3744766464 /dev/sdb4 /dev/sdc4 missing /dev/sda1 /dev/sde4 /dev/sdg1 /dev/sdf1 for 6 drives, respectively mdadm --create --assume-clean --level=6 --raid-devices=7 --size=3744766464 /dev/sdb4 /dev/sdc4 missing missing /dev/sde4 /dev/sdg1 /dev/sdf1 on a 5 drive solution. Would you agree with this?

我还没有核实细节（驱动器顺序、大小、缺失位置等），但命令看起来不错。不过，正如 Linux Raid Wiki 上提到的那样，重新创建应该被视为最后的求助。当需要这样做时，我总是尽量做到尽可能具体。只需记住，我上次查看了 mdadm 手册页并添加了所有我知道数据的选项（例如，甚至是块大小、对齐方式等）。有很多默认值可以省略，但是当确定值时，为什么不具体一点呢。

针对您的情况，我会尝试以下方法：

调mdadm出一个版本>=4.0
停止阵列（如果正在运行）。检查/proc/mdstat并使用mdadm --stop ...。
验证磁盘和 HBA（sata/ide/scsi 控制器）。检查dmesg和smartctl记录。尝试从磁盘读取（例如。。dd if=/dev/hda1 of=/dev/null bs=1M count=2048重新检查dmesg和smartctl记录。重复此操作，添加一些ibs=和skip=。重新检查dmesg和记录。如果您在 HBA上smartctl看到任何内容，请停止使用该硬件的磁盘上的任何程序。resets|timeouts|failuresata|sata|scsi|...
在所有磁盘上重复验证磁盘和 HBA。
运行mdadm --assemble --scan --verbose。这很可能会失败，但它可以让您很好地了解 mdadm 发现了什么，并让您了解当您force这样做时会发生什么。
研究上述输出，检查您所看到的内容是否与您已经收集的有关驱动器/阵列的信息相符。
停止阵列（如果它正在运行或者已启动）。
如果您对 mdadm 的操作感到满意--assemble --scan --verbose，请尝试一下--force。
如果所有这些都失败了，请进行全盘备份（或创建覆盖文件），然后返回到最后的采取并重新创建整个阵列，使用assume-clean和从阵列收集的所有信息。

交换磁盘前的状态

交换磁盘前的状态

实际状态

澄清事实

更多输出

阵列设备超级块

答案1

答案2

答案3

答案4

相关内容