☰

raid5出现问题后，raid5+lvm reiserfs分区上的数据恢复

tag-icon • tag-icon linux lvm data-recovery reiserfs
raid5出现问题后，raid5+lvm reiserfs分区上的数据恢复

我有一台带有 3 个SATA 硬盘的服务器。每个分区都有 2 个分区：一小部分是 /dev/md0 的一部分，即 raid1 阵列 (/boot)，其余部分是 raid5 阵列 (/dev/md1) 的一部分，这是一个 lvm 物理卷。其内部有 3 个 (IIRC) 逻辑卷。其中之一是 reiserfs 3.6 fs，可容纳大约 100gigs 数据。

昨天这个服务器崩溃了。启动时，SMART 告诉我其中一个驱动器已损坏。他确实发出了非常难听的声音。因此，我删除了出现故障的驱动器，并尝试在剩余的 2 个磁盘上重新启动系统。哪个失败了。

我使用 live CD 启动它并尝试重新启动阵列。不幸的是，mdadm 拒绝这样做，因为它认为剩下的 2 个磁盘之一也出现了故障。

因此，遵循在以下位置找到的建议如何恢复崩溃的 Linux md RAID5 阵列？看起来它可以适用于我的情况，我做了一些可能只是愚蠢的事情：我跑了

mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sd[ab]2 missing

现在，我实际上可以启动这个阵列，但是lvm工具（vgscan、vgdisplay、pvck）无法在阵列上找到与lvm相关的任何内容，并且我完全无法获取我的数据。我刚刚擦除了所有 lvm 元数据吗？

我的感觉是实际数据仍然存在，未损坏（除了 lvm 元数据）。有机会取回数据吗？如何？

更新：

根据 psusi（如下）的建议，我尝试了以下每种重新创建数组的方法：

mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sdb2 /dev/sda2

mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sdb2 /dev/sda2

这基本上是所有可能的命令，包括 -c64 和 -c512。每次测试后，我都会运行 vgscan。没有人发现任何东西。也许我不应该使用 vgscan 而应该使用其他工具？

更新2：

我尝试重新连接出现故障的硬盘。奇迹，它似乎有点作用。至少，足以检查它：

root@debian:~# mdadm --examine /dev/sda2
/dev/sda2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 1f5462ab:6945560d:019b01a5:914dd464
  Creation Time : Fri Oct 17 12:40:40 2008
     Raid Level : raid5
  Used Dev Size : 160015360 (152.60 GiB 163.86 GB)
     Array Size : 320030720 (305.21 GiB 327.71 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 1

    Update Time : Tue Apr 12 08:15:03 2011
          State : active
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 64d514fb - correct
         Events : 137

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     0       8        2        0      active sync   /dev/sda2
   0     0       8        2        0      active sync   /dev/sda2
   1     1       8       18        1      active sync   /dev/sdb2
   2     2       8       34        2      active sync   /dev/sdc2

那么，有没有办法将此超级块复制到其他两个设备，以便我可以“正确”启动阵列？

答案1

我有类似的设置，我可以建议在每个驱动器的小分区上安装一个完整的 Linux，不是镜像那些小分区，但让它们单独完全可启动。

您可以sync在安装时排除一些关键文件（/etc/fstab、grub 配置）。这不仅需要更多的空间，/boot而且在遇到麻烦时可以节省大量时间。

答案2

您可能没有按照以前的顺序组装驱动器，或者没有使用与以前相同的块大小。您需要弄清楚之前的顺序是什么，并在重新创建数组时使用相同的顺序。换句话说，死掉的可能不是第三个磁盘，而是第一个或第二个，我们的你可能把sda和sdb搞混了。

答案3

作为 @普苏西 暗示元数据格式是 kye，看起来 — 现在“1.2”是默认值，而不是“0.9”。遗憾的是，这可能会导致数据丢失，因为 1.2 使用 4 KiB 偏移量：

1、1.0、1.1、1.2 默认使用新的 version-1 格式超级块。这样限制较少。它可以轻松地在具有不同字节序的主机之间移动，并且可以设置检查点并重新启动恢复操作。不同的子版本将超级块存储在设备上的不同位置，要么在末尾（对于 1.0），要么在开头（对于 1.1），要么从开头开始 4K（对于 1.2）。

一个建议（唉，迟到了）：永远不要急于重新创建一个数组而不尝试使用-B- build：

   -B, --build
          Build a legacy array without superblocks

UPD.: 结果-B拒绝构建 RAID-5...:-/

相关内容