MD，部分从 RAID1 增长到 RAID5，但被中断，磁盘被移除，现在文件系统一片混乱

Question

在彻底破坏不断增长的 RAID5 之后，我如何挽救我的数据！

我有一个 3 磁盘 RAID5 阵列，其中设备编号 3 丢失，并且数据似乎已损坏。

/dev/sdd5：（5.45 TiB）6TB，阵列的设备 1

/dev/sde5：（5.45 TiB）6TB，阵列的设备 2

阵列正在从 RAID1 转换为 RAID5，这时操作被中断，设备 3 被移除。阵列仍在运行，直到设备 2 也被移除。当设备 2 放回原位时，文件系统无法挂载。/dev/md2 设备被克隆，并在克隆的分区上运行 fsck，发现数百万个错误。

在转换中断和移除磁盘后，MD 显然没有正确处理 RAID 数据。我去调查发生了什么：

首先，我查看了一下/var/log/space_operation_error.log，它告诉我到底发生了什么。一旦磁盘 2 被移除，RAID 的状态就会变为损坏，因为 3 磁盘 RAID5 无法用 1 个磁盘运行。但这也让 RAID 忘记了它正在从 RAID1 重塑为 RAID5。

因此，我认为数据损坏可能是由于 MD 将整个数据视为 RAID5 编码，而其中一部分仍处于原始状态所致。

检查设备的 RAID 数据对我没有帮助，一切看起来都很好：

# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md124 : active raid5 sda5[0] sdb5[1]
      11711575296 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/2] [UU_]

# mdadm -E /dev/sda5
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 58290cba:75757ee2:86fe074c:ada2e6d2
           Name : DiskStation:2
  Creation Time : Thu Nov 27 11:35:34 2014
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 11711575680 (5584.51 GiB 5996.33 GB)
     Array Size : 23423150592 (11169.03 GiB 11992.65 GB)
  Used Dev Size : 11711575296 (5584.51 GiB 5996.33 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 1a222812:ac39920b:4cec73c4:81aa9b63

    Update Time : Fri Mar 17 23:14:25 2017
       Checksum : cb34324c - correct
         Events : 31468

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 0
   Array State : AA. ('A' == active, '.' == missing)

但我认为它必须有某种计数器，以便在重塑时跟踪其进度。我研究了 MD 超级块的格式，如下所述： https://raid.wiki.kernel.org/index.php/RAID_superblock_formats

我复制了其中一个 RAID 分区的前 10 MiB（mdadm -E 在较小的副本上不起作用）：

# dd if=/dev/sda5 of=/volume1/homes/sda5_10M.img bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0622844 s, 168 MB/s

我在十六进制编辑器中打开它，并将字节 4104 处的数据从 0x00 更改为 0x04，以表明重塑正在进行中。

我还注意到从 4200 开始的 8 个字节的值。它读取的是 3856372992。

保存更改后，我检查了副本：

# mdadm -E /volume1/homes/sda5_10M.img
/volume1/homes/sda5_10M.img:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x4
     Array UUID : 58290cba:75757ee2:86fe074c:ada2e6d2
           Name : DiskStation:2
  Creation Time : Thu Nov 27 11:35:34 2014
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 11711575680 (5584.51 GiB 5996.33 GB)
     Array Size : 23423150592 (11169.03 GiB 11992.65 GB)
  Used Dev Size : 11711575296 (5584.51 GiB 5996.33 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 1a222812:ac39920b:4cec73c4:81aa9b63

  Reshape pos'n : 1928186496 (1838.86 GiB 1974.46 GB)
  Delta Devices : 1 (2->3)

    Update Time : Fri Mar 17 23:14:25 2017
       Checksum : cb34324c - expected cb343250
         Events : 31468

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 0
   Array State : AA. ('A' == active, '.' == missing)

如您所见，它报告了重塑进度的准确位置 - 这也告诉我之前得到的数字是 512 字节扇区的数量。

现在知道了前 1838.86 GiB 在重塑过程中被覆盖，我认为其余分区未受影响。

因此，我决定组装一个块设备，从新的 RAID5 部分和未触及的部分开始，在报告的 respape 位置处切割（阅读下面关于假设位置的说明）。由于数据偏移量为 2048 个扇区，我需要将 1024KiB 添加到大小，以获取原始分区部分的偏移量：

#losetup -f --show /dev/md124 --sizelimit=1928186496K
/dev/loop0

#losetup -f --show /dev/sda5 --offset=1928187520K 
/dev/loop1

为了组装各个部件，我创建了一个没有元数据的 JBOD 设备：

# mdadm --build --raid-devices=2 --level=linear /dev/md9 /dev/loop0 /dev/loop1
mdadm: array /dev/md9 built and started.

然后我检查了新的 /dev/md9 设备的内容

# file -s /dev/md9
/dev/md9: LVM2 PV (Linux Logical Volume Manager), UUID: xmhBdx-uED6-hN53-HOeU-ONy1-29Yc-VfIDQt, size: 5996326551552

由于 RAID 包含 LVM 卷，我需要跳过前 576KiB 才能进入 ext4 文件系统：

# losetup -f --show /dev/md9 --offset=576K
/dev/loop2

# file -s /dev/loop2
/dev/loop2: Linux rev 1.0 ext4 filesystem data, UUID=8e240e88-4d2b-4de8-bcaa-0836f9b70bb5, volume name "1.42.6-5004" (errors) (extents) (64bit) (large files) (huge files)

现在我将文件系统安装到 NAS 上的共享文件夹中：

# mount -o ro,noload /dev/loop2 /volume1/homes/fixraid/

我的文件就可以访问了！

在决定上面使用的位置大小/偏移量之前，我尝试了几个值。我的第一个想法是，由于每个设备的 1838.86 GiB 被重塑，RAID5 部分将包含约 3.6 TiB 的有效数据，我使用的位置是重塑位置的两倍。它安装得很好，但我的一些文件似乎包含无效数据，一些文件在读取时出现 I/O 错误，一些文件夹丢失了。

由于我有很多 NEF（尼康）格式的 RAW 照片，因此我决定使用文件工具对其中一些进行测试。

预期结果：

# file DSC_7421.NEF
DSC_7421.NEF: TIFF image data, little-endian, direntries=28, height=120, bps=352, compression=none, PhotometricIntepretation=RGB, manufacturer=NIKON CORPORATION, model=NIKON D750, orientation=upper-left, width=160

数据损坏时的结果：

# file DSC_9974.NEF
DSC_9974.NEF: data

ls当我在某些文件夹中写入时，我也遇到了一些 I/O 错误。

我决定查看一些大型照片集并测试它们的完整性 - 首先列出文件并计算输出中的行数。然后应将任何读取错误写入屏幕。接下来，通过检查是否有任何 NEF 文件无法识别，指示数据损坏。我过滤了文件的输出并计算了过滤后的行数。

# ls *.NEF -1 | wc -l
3641
# file *.NEF | grep "NEF: data" | wc -l
0

我对我的许多照片文件夹都执行了此操作，以确保所有文件均可读且其内容可被识别。

使用 3856372992K 大小和 3856374016K 偏移量，我得到了很多无效数据和丢失的文件/文件夹，并且我尝试了其他几个值。

我发现上面提到的偏移量和大小似乎通过了我的小测试。！

如上所示，文件系统报告了一些错误。由于我不想在恢复所有内容之前将任何数据写入我的设备，因此我决定制作快照写入覆盖，因此 fsck.ext4 进行的所有写入都将写入此文件。

创建一个 50GiB 稀疏文件

# truncate /volume1/overlay.img -s50G

创建虚拟设备

#losetup -f --show /volume1/overlay.img 
/dev/loop3

通过数据获取设备的大小：

# blockdev --getsz /dev/loop2
11711574528

创建覆盖设备（在此之前，我已卸载了 /dev/loop2 处的文件系统）

# dmsetup create overlay --table "0 11711574528 snapshot /dev/loop2 /dev/loop3 P 8"

该设备可在/dev/mapper/overlay

最后我可以检查并修复错误：

# fsck.ext4 -y -C 0 /dev/mapper/overlay

请注意，修复仅写入覆盖文件，如果它们是永久的，则需要提交到物理磁盘。

Answer 1