☰

正在运行 LVM2 的 RAID5 救援

tag-icon • tag-icon linux debian lvm raid5 data-recovery
正在运行 LVM2 的 RAID5 救援

我有一个由 6 个 1TB 驱动器组成的 RAID5 阵列。最近由于硬件更改，我需要重新创建 RAID 以重写每个驱动器上的引导加载程序。

现在问题来了。启动 Debian 救援系统时，出现了 mdadm --create。到目前为止，糟糕的情况。

我尝试重新组装设备，但原始设置不再可用。当我使用

mdadm --examine --scan

输出仅显示 2015 年 4 月 27 日创建的阵列，原始 raid 是在 2012 年 12 月创建的。

我已经认识到，在构建命令期间，驱动器的顺序是重要的这让我陷入了探索每种组合的境地。到目前为止，我们已经6！ = 720插入所有设备的不同可能性。

使用以下方法对分区进行迭代，实现自动化：

mdadm --create /dev/md0 --readonly --level=5 --assume-clean --raid-devices=6 /dev/sdd2 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdf2 /dev/sde2

只得到四十四组合解决了超出范围的 LVM 记录问题。我以为我已经搞定了。

真正的问题现在开始了。当我运行：

pvscan

显示并激活了该卷，列出了所有三个卷：

nas-root
nas-swap
nas-storage

现在的问题是，在这 44 种组合中，我都无法安装系统。

它显示一个错误，提示 NTFS 签名无效。但是上面应该有一个 ext3/4 文件系统。

是否可能按正确的顺序组装阵列但条带大小错误而发生这种情况？

由于我在 2012 年 12 月创建了该数组，因此我假设使用了默认设置，这意味着512 块大小，左对称突袭5。

当我运行多个

mdadm --create ... --chunk=X /dev/sd* (in different order)

补充说明：

扫描使用 -d 打印出它正在降级的 raid 上运行。也许这就是问题所在？但如何解决呢？

其他帮助：

为了支持完整的测试，我在 raid 上创建了一个只读覆盖（因为我没有空间来映像所有 1 TB 磁盘）。

对于其他用户这可能有用：

#!/bin/bash
dev=$1
tmp="/tmp"
if [ "no$dev" == "no" ]; then
    echo "Usage $0 /dev/sdx."
    echo "Overlays are placed in $tmp"
    exit 1
fi

base=`basename $dev`
ovl="$tmp/overlay.$base"
if [ -e $ovl ]
then
   rm $ovl
fi
truncate -s50G $ovl
newdev="$base-ovl"
size=$(blockdev --getsize "$dev")
# you need to have enough loop devices
loop=$(losetup -f --show "$ovl")

printf '%s\n' "0 $size snapshot $dev $loop P 8" | dmsetup create "$newdev"

您还可以将图像绑定到环回并将其连接到覆盖。

到目前为止对我有帮助的是：

答案1

组装阵列时，两个都驱动器顺序和块大小至关重要。请注意，虽然 Linux 软件 RAID 最近切换到使用 512K 大小的块，但几年前它使用的是 64K 大小的块。

这意味着您之前的数组可能是使用旧的默认 64K 块创建的。请重试使用 64K 块组装数组并报告结果。

答案2

我意识到在构建命令期间，驱动器的顺序很重要。这让我陷入了探索每种组合的情况。到目前为止，我们有 6！= 720 种不同的可能性来插入所有设备。

这就是秘密，我一直在努力，直到我读到它......阵列的顺序很重要，多亏了你，我才能恢复我所有的数据。

对我来说这比较简单，因为我知道哪一个是最后一个磁盘（较大的那个），所以我有一个 3！拼图，它有 6 种不同的解决方案，我可以解决它。

多谢。

相关内容