Linux软件RAID恢复

Question

我看到了mdadm输出的差异--细节和mdadm --检查，我不明白为什么。

这个输出

mdadm --detail /dev/md2
/dev/md2:
        Version : 0.90
  Creation Time : Wed Mar 14 18:20:52 2012
     Raid Level : raid10
     Array Size : 3662760640 (3493.08 GiB 3750.67 GB)
  Used Dev Size : 1465104256 (1397.23 GiB 1500.27 GB)
   Raid Devices : 5
  Total Devices : 5
Preferred Minor : 2
    Persistence : Superblock is persistent

似乎与此相矛盾。(数组中的每个磁盘相同)

mdadm --examine /dev/sdc2
/dev/sdc2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 1f54d708:60227dd6:163c2a05:89fa2e07 (local to host)
  Creation Time : Wed Mar 14 18:20:52 2012
     Raid Level : raid10
  Used Dev Size : 1465104320 (1397.23 GiB 1500.27 GB)
     Array Size : 2930208640 (2794.46 GiB 3000.53 GB)
   Raid Devices : 5
  Total Devices : 5
Preferred Minor : 2

数组是这样创建的。

mdadm -v --create  /dev/md2 \
  --level=raid10 --layout=o2 --raid-devices=5 \
  --chunk=64 --metadata=0.90 \
 /dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2 

5个驱动器中的每一个都有这样的分区。

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00057754

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048       34815       16384   83  Linux
/dev/sdc2           34816  2930243583  1465104384   fd  Linux raid autodetect

背景故事

所以SATA控制器在我提供一些支持的盒子中失败了。失败是一个丑陋的，因此个别驱动器从阵列中掉了一点点。虽然有备份，但我们并没有真正做到我们真正需要的频率。有一些数据，我正试图恢复，如果可以的话。

我有额外的硬件，我能够再次访问驱动器。驱动器看起来很好，我可以激活和挂载数组和文件系统(使用只读模式)。我能够访问文件系统上的一些数据，并且一直在复制这些数据，但是当我试图复制最新的数据时，我看到了很多错误。

当我试图访问最近的数据时，我得到的错误如下所示，这使我认为数组大小的差异可能是问题所在。

Mar 14 18:26:04 server kernel: [351588.196299] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.196309] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.196313] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.199260] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.199264] dm-7: rw=0, want=20647626304, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.202446] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.202450] dm-7: rw=0, want=19973212288, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.205516] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.205520] dm-7: rw=0, want=8009695096, limit=6442450944

Answer 1

如果你能用dd克隆硬盘，我就会那么做。保持您的原始驱动器尽可能不被触及。

然后，这是一个完全从臀部拍摄，但我会尝试，如果我是在那种情况下。使用系统中的克隆驱动器，我将使用以下方法删除所有RAID元数据。

mdadm --zero-superblock /dev/sdx#

在每一个驱动器上。

然后使用命令重新创建数组。

mdadm -v --create /dev/md2 \

--level=raid10 --layout=o2 --raid-devices=5 \

--chunk=64 --metadata=0.90 --assume-clean \

/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2

这应该可以消除所有raid级别的问题。从那里，您可以尝试重新装入文件系统，看看还剩下什么。如果这样做不起作用，那么就重新克隆您的驱动器，并尝试其他方法:)

Answer 2

您确定要创建数组的命令行吗？我的猜测是，它是一个“标准”4驱动器raid10数组和一个热备用驱动器，这将解释/dev/sdc2 2的结果

你能告诉我们以下的结果吗？

cat /proc/mdstat
cat /etc/mdadm.conf
mdadm --examine /dev/sdx2 ( each drive )

有了这个，您可能能够猜出哪个驱动器是热备用的，因此您将能够正确地重建数组。当然，正如3dImpact所述，在尝试重新配置数组之前，您应该复制数据。

编辑:而且，运行它也不是浪费时间:在每个驱动器上运行smartctl -a /dev/sdx (如果有错误报告，请在输出结束时检查)，然后再运行一个smartcl -t long /dev/sdx和3或4个小时后再运行smartctl -a来检查5个磁盘是很好的。如果一个磁盘正在报告错误，那么mdadm可能检测到它是错误的，所以mdadm打开了备用驱动器(总是猜测)。

编辑2:如果vgs报告: vgdisplay显示的是异种PE/大小为3.00 TiB，则表示您的PV神秘地增长了421 G。我站在我的立场：“神秘”增长是一个错误的配置你的阵列。数组的实际大小是3T。你没有正确地重新组装它，所以它是腐败的。为了正确地重新组装它，您需要检索原始配置，以及哪个驱动器是备用驱动器。祝好运。