☰

添加新磁盘后，mdadm raid 出现未知文件系统

tag-icon • tag-icon linux raid ext4 mdadm filesystem-corruption
添加新磁盘后，mdadm raid 出现未知文件系统

我的电脑运行的是 ubuntu 1804，但我对 Linux 还不熟悉。
我使用 mdadm 并创建了一个带有 3 个 4TB 驱动器（sda、sdb sdc）的 raid-5。
操作系统位于单独的 SSD（sde）上。
不，我没有备份。是的，认为一切都会好起来是愚蠢的。但我没有足够的空间来备份我的 8TB raid。

我想在我的 raid 上留出更多空间，所以我按照以下方法添加了另一个驱动器 (sdd)指示并且它成功了。

我遇到的一个问题是，每次重启后我的 raid 都会消失，所以我认为重新安装 mdadm 可能会有帮助。
我这样做之后，重新启动并使用以下命令创建阵列：

sudo mdadm --create --assume-clean --level=5 --raid-devices=4 /dev/md0 /dev/sda /dev/sdb /dev/sdc /dev/sdd

（因为“--assemble --scan”不起作用）文件系统不再被识别。

然后我多次创建了阵列，因为我在某处读到过，如果驱动器的顺序错误，就会发生这种情况。这没有用。

检查文件系统返回了以下信息：

challenger1304@hannes:~$ sudo fsck /dev/md0 
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md0

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

然后我尝试按照工具的指示替换损坏的超级块。为了查看超级块备份可能在哪里，我运行了“mkfs.ext4 -n /dev/md0”，并尝试了其中的大部分方法。但
都没有成功。

经过进一步的研究，我找到了一个名为“TestDisk”的工具，安装并运行它。发现很多分区（磁盘阵列上只有一个）带有正确的标签。这些分区中没有文件，工具无法重新创建分区。
我以不同的顺序重新创建磁盘阵列后，已经这样做了三次。每次都是同样的结果。

答案1

前言

我正在使用 mdadm 并创建了一个带有 3x 4TB 驱动器（sda、sdb sdc）的 raid-5

使用 raid5 来处理如此大的驱动器无异于自找麻烦。您可以在互联网上找到许多反对这样做的警告，但我再次警告您：您的数据处于危险之中。一旦 raid5 阵列中的一个磁盘发生故障，您就完全没有冗余了。一旦您插入新的备用磁盘并启动重新同步过程，另一个磁盘出现读取错误的可能性就很高。一旦发生这种情况，您的数据就没了。

然后，另一个建议：我总是制作分区的 RAID 阵列，而不是整个磁盘的 RAID 阵列。但这有点像“偏好”，自从我了解 mdadm raid 以来，我就一直遵循这个偏好。实际上，我的所有磁盘都包含多个 RAID（例如：raid1 中的第一个分区带有操作系统，然后是更大的 RAID 的另一个分区）。

不，我没有备份。是的，认为一切都会好起来是愚蠢的。但我没有足够的空间来备份我的 8TB 磁盘阵列。

很公平。这意味着你不太在意是否会丢失这些数据，尤其是在扩充/重塑 RAID 阵列这种精细的操作中。正如你在Linux RAID Wiki 中有关扩大阵列的内容，章节标题之后的第一部作品是：

备份。备份！！备份！！！！

回归正题

让我们尝试了解您在此处描述的步骤中发生了什么。

我遇到的一个问题是，每次重启后我的团队都会消失

这应该让你停下来问：出了什么问题？ 在我丢失所有数据之前，让我们解决这个问题。

可能你忘了填充，或者更好的是，更新您的/etc/mdadm/mdadm.conf文件中有类似如下的一行：

ARRAY /dev/md/0 metadata=1.2 UUID=deadbeef:deadbeef:deadbeef:deadbeef name=myhostname:0

您可以使用它来生成

 mdadm --detail --scan

并且，你可能需要更新你的 initramfs。在 Debian 上，你可以使用以下命令进行更新

update-initramfs -u

所以我认为重新安装 mdadm 可能会有帮助。

一点帮助都没有。

完成此操作后，重新启动并使用以下命令创建阵列：

sudo mdadm --create --assume-clean --level=5 --raid-devices=4 /dev/md0 /dev/sda /dev/sdb /dev/sdc /dev/sdd

哦不。哇，您现在已经覆盖了所有四个磁盘上的 RAID 超级块。您的数据仍然存在，但您已经覆盖了告诉 mdadm 您的 RAID 阵列布局的信息。假设旧超级块和新超级块是同一版本 (1.2)，您可以通过使用原始磁盘的备份覆盖 RAID 超级块来恢复这种情况。

（因为“--assemble --scan”不起作用）

这应该会阻止您继续操作，并搜索有关返回错误的更多信息。很可能驱动器上的数据布局不是 mdadm 所期望的布局，或类似情况。本身不是什么大问题。

然后我多次创建了阵列，因为我在某处读到过，如果驱动器的顺序错误，就会发生这种情况。这没有用。

您一次又一次地覆盖了所有磁盘上的 RAID 超级块。您的数据没有变化（假设新旧 RAID 超级块是同一版本）

然后我尝试按照工具的指示替换损坏的超级块。

哦天哪，不不不！你从这里开始破坏数据。现在没有机会完整地恢复所有数据，因为你将数据写入了一个未知的位置（相对于增长数组的原始布局）。

经过进一步研究，我找到了一个名为“TestDisk”的工具，安装并运行它。发现很多分区（磁盘阵列上只有一个）带有正确的标签。这些分区中没有文件，并且该工具无法重新创建分区。

该工具直接读取块设备（RAID 阵列），而不使用文件系统，并且可能正在查看由错误顺序的块组成的一些数据。完全没有意义。

怎么办？

我认为你可以告别旧数据了。但是，由于你只是向数组写入了少量数据，因此一旦你找出原始数组的设置方式，你就有可能恢复数据。这包括找出：

  • 数组的大小
  • 数组布局（左对称等）
  • 条带大小
  • 磁盘顺序

如果没有 RAID 超级块的备份，那么这将非常困难。不幸的是，您通过艰苦的努力才学到了“进行备份”的建议。祝您好运！

相关内容