raid5+lvm reiserfs分区上数据的恢复，在raid5问题发生后

Question

我有一台服务器，里面有3个sata硬盘。每个分区都有两个分区:一个小分区是/dev/md0的一部分，一个是raid1数组(/boot)，rest是一个raid5数组(/dev/md1)的一部分，它是一个lvm物理卷。里面是3 (IIRC)逻辑卷。其中一个是ReiserFS3.6fs，包含大约100 fs的数据。

昨天这台服务器崩溃了。在停电的时候，SMART告诉我其中一个硬盘坏了。他确实发出了很坏的声音。因此，我删除了失败的驱动器，并试图重新启动系统上的2个剩余的磁盘。但失败了。

使用一张活动cd，我启动它并尝试重新启动数组。不幸的是，mdadm拒绝这么做，因为它认为剩下的两个磁盘中的一个也失败了。

因此，按照在如何恢复崩溃的Linux RAID5 5数组？上发现的似乎适用于我的情况的建议，我做了一件可能很愚蠢的事情:我跑了

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，而应该使用其他一些工具？

更新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

那么，有没有办法将这个超级块复制到其他两个设备上，这样我就可以“正确”启动数组了吗？

Answer 1

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

您可以在sync设置中排除一些关键文件(/etc/fstab、grub配置)。这不仅占用了/boot更多的空间，但在遇到麻烦时节省了很多时间。

Answer 2

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

Answer 3

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

1，1.0，1.1，1.2默认使用新版本-1格式的超级块。这方面的限制较少。它可以很容易地在具有不同端点的主机之间移动，并且可以对恢复操作进行检查和重新启动。不同的子版本将超级块存储在设备的不同位置，要么在终端(对于1.0)，要么在启动(对于1.1)，或者从开始(对于1.2)的4K。

一个建议(唉，晚一点)：不要急于重新创建数组w/o，尝试使用-B - build：

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

原来-B拒绝构建RAID-5…*-/