意外将最后 2 个驱动器重新初始化为 RAID0 后恢复 4 个驱动器 RAID5 阵列

Question 1

如果您没有多余的空间资源来存储至少两倍于阵列原始大小的数据，例如，如果您没有至少 3 TB * 4 个驱动器 * 2 = 24 TB 的可用空间用于恢复操作，请停止并将整个工作交给专业的数据恢复服务。

现在，答案来了。

如果它运行mdadm --create 没有 --assume-clean是的，数据被零覆盖了。
不可以。您不能更改驱动器上的任何内容。您首先需要执行的步骤是转储 (图像) RAID 的所有四个成员。
不是。这些超级块是不同的。它们中有些东西应该相同，有些东西应该不同。特别是，每个超级块都记录了这阵列中的设备。

如 (1) 中所述，最有可能的是位于阵列开头的数据被不可逆转地破坏（就像 RAID5 中的两个驱动器同时丢失一样）。可能有可能恢复位于停止过程的位置的“尾部”。这并不一定意味着你能够恢复用户数据它就在那里，因为驻留在那儿的文件系统结构大概也依赖于位于损坏区域中的块。但是正常的文件系统会有许多超级块的副本，这些副本可能恰好位于未损坏区域中，所以仍然有希望。您可以尝试揭示这个未损坏的尾部并从中恢复可能的内容。

首先进行必要的备份所有四个设备如 (2) 中所述（使用例如dd或ddrescue）。这将使用一半的备用空间。
然后，你可以继续使用重新创建阵列mdadm --create -e1.2 -l5 -n4 --assume-clean /dev/sd[abcd]4。请注意驱动器的顺序，正如我在上面的命令中介绍的那样很可能顺序不正确。你需要玩一会儿才能猜出正确的顺序；可能正确的顺序应该是[cbda]或[dbca]，因为幸存的设备有顺序：sda4=3，sdb4=1（取自设备角色属性）。如果您猜错了，则必须将转储复制回驱动器并重新开始；这就是转储的用途，但请参阅下面的提示。理想情况下，这需要的猜测次数不超过 2 次。最多有 4！= 1 * 2 * 3 * 4 = 4 个驱动器的 24 种不同排序。

您应该期望的是，数组末尾的数据恰好是干净的。如何检查，取决于您那里有什么。您的数组使用块大小 64KiB，因此您必须检查数组上 64KiB 的数据段是否以正确的顺序排列。再次，请参阅提示以简化猜测过程。

当找到正确的顺序时，你就可以丢弃组装阵列的图像到剩余的备用可用空间。现在您将在阵列上执行文件系统恢复操作。如果是 ext4，您可以尝试运行e2fsck -b <superblock>，指定未损坏区域中的超级块；您可以通过运行mke2fs -n模拟文件系统创建而不实际写入任何内容来猜测哪个超级块。基本上，您在此步骤后得到的就是可以恢复的内容。

提示。在获取所需的完整转储后，您可以通过实例化读写覆盖来加快猜测过程，这样就不会更改驱动器上的数据。如果猜测错误，您只需要重新创建覆盖映像，而不是将转储复制回驱动器，这比复制 12 TB 要快得多。我描述了这一点在另一个答案中但是对于您的问题，您不是为组装的阵列制作覆盖，而是为四个单独的设备制作覆盖，然后从分层的 nbdX 设备构建阵列。

这还可以让您跳过转储文件系统映像。您可以同时在这些转储中执行所有 2 个甚至所有 24 个可能的顺序（这将分别需要 8 个或 96 个覆盖映像和 NBD，但所有这些映像都只包含更改，并且在此类恢复操作期间往往不会增长太多）。然后尝试在每个映像上恢复文件系统，看看哪一个是正确的。然后删除所有不正确的尝试，将文件系统的内容复制到备用可用空间，删除设备上的阵列并重新创建它们，然后将幸存的数据复制回来。

Answer

如果您没有多余的空间资源来存储至少两倍于阵列原始大小的数据，例如，如果您没有至少 3 TB * 4 个驱动器 * 2 = 24 TB 的可用空间用于恢复操作，请停止并将整个工作交给专业的数据恢复服务。

现在，答案来了。

如果它运行mdadm --create 没有 --assume-clean是的，数据被零覆盖了。
不可以。您不能更改驱动器上的任何内容。您首先需要执行的步骤是转储 (图像) RAID 的所有四个成员。
不是。这些超级块是不同的。它们中有些东西应该相同，有些东西应该不同。特别是，每个超级块都记录了这阵列中的设备。

如 (1) 中所述，最有可能的是位于阵列开头的数据被不可逆转地破坏（就像 RAID5 中的两个驱动器同时丢失一样）。可能有可能恢复位于停止过程的位置的“尾部”。这并不一定意味着你能够恢复用户数据它就在那里，因为驻留在那儿的文件系统结构大概也依赖于位于损坏区域中的块。但是正常的文件系统会有许多超级块的副本，这些副本可能恰好位于未损坏区域中，所以仍然有希望。您可以尝试揭示这个未损坏的尾部并从中恢复可能的内容。

首先进行必要的备份所有四个设备如 (2) 中所述（使用例如dd或ddrescue）。这将使用一半的备用空间。
然后，你可以继续使用重新创建阵列mdadm --create -e1.2 -l5 -n4 --assume-clean /dev/sd[abcd]4。请注意驱动器的顺序，正如我在上面的命令中介绍的那样很可能顺序不正确。你需要玩一会儿才能猜出正确的顺序；可能正确的顺序应该是[cbda]或[dbca]，因为幸存的设备有顺序：sda4=3，sdb4=1（取自设备角色属性）。如果您猜错了，则必须将转储复制回驱动器并重新开始；这就是转储的用途，但请参阅下面的提示。理想情况下，这需要的猜测次数不超过 2 次。最多有 4！= 1 * 2 * 3 * 4 = 4 个驱动器的 24 种不同排序。

您应该期望的是，数组末尾的数据恰好是干净的。如何检查，取决于您那里有什么。您的数组使用块大小 64KiB，因此您必须检查数组上 64KiB 的数据段是否以正确的顺序排列。再次，请参阅提示以简化猜测过程。

当找到正确的顺序时，你就可以丢弃组装阵列的图像到剩余的备用可用空间。现在您将在阵列上执行文件系统恢复操作。如果是 ext4，您可以尝试运行e2fsck -b <superblock>，指定未损坏区域中的超级块；您可以通过运行mke2fs -n模拟文件系统创建而不实际写入任何内容来猜测哪个超级块。基本上，您在此步骤后得到的就是可以恢复的内容。

提示。在获取所需的完整转储后，您可以通过实例化读写覆盖来加快猜测过程，这样就不会更改驱动器上的数据。如果猜测错误，您只需要重新创建覆盖映像，而不是将转储复制回驱动器，这比复制 12 TB 要快得多。我描述了这一点在另一个答案中但是对于您的问题，您不是为组装的阵列制作覆盖，而是为四个单独的设备制作覆盖，然后从分层的 nbdX 设备构建阵列。

这还可以让您跳过转储文件系统映像。您可以同时在这些转储中执行所有 2 个甚至所有 24 个可能的顺序（这将分别需要 8 个或 96 个覆盖映像和 NBD，但所有这些映像都只包含更改，并且在此类恢复操作期间往往不会增长太多）。然后尝试在每个映像上恢复文件系统，看看哪一个是正确的。然后删除所有不正确的尝试，将文件系统的内容复制到备用可用空间，删除设备上的阵列并重新创建它们，然后将幸存的数据复制回来。

Question 2

总结
仅当您覆盖了不同的 RAID 配置/文件系统（因为备份超级块位置不同，旧超级块不会被覆盖）并且旧文件系统是 EXT4/3 时才有效。并且没有物理损坏。恢复的关键是备份超级块存在。

如果只有 EXT4 的第一部分损坏，应该可以用此方法恢复其文件结构

情况：4 个 RAID 5 驱动器中的 2 个被覆盖了其标头（通过重新初始化新 raid 并在其中创建新的 ext4），另外 2 个保持不变。

首先备份，或者将这 4 个驱动器以只读方式安装在 PC 上。对我来说，旧的 raid 是 /dev/sd{b,c,d,e}4。

blockdev --setro /dev/sd{b,c,d,e}4 # check the device using lsblk

为它们设置覆盖块设备（@Nikita Kipriyanov 提到，它确实使操作更加高效）

modprobe nbd
apt update && apt install qemu-utils -y
# create tmp file to hold changes
qemu-img create -f qcow2 -b /dev/sdb4 -F raw /tmp/sdb4.qcow2
qemu-img create -f qcow2 -b /dev/sdc4 -F raw /tmp/sdc4.qcow2
qemu-img create -f qcow2 -b /dev/sdd4 -F raw /tmp/sdd4.qcow2
qemu-img create -f qcow2 -b /dev/sde4 -F raw /tmp/sde4.qcow2
# mount nbd[1-4] as an overlay device of `/dev/sd[bcde]4`
qemu-nbd -c /dev/nbd0 /tmp/sdb4.qcow2 
qemu-nbd -c /dev/nbd1 /tmp/sdc4.qcow2 
qemu-nbd -c /dev/nbd2 /tmp/sdd4.qcow2 
qemu-nbd -c /dev/nbd3 /tmp/sde4.qcow2

你可以通过重新创建 nbd 设备重新开始

mdadm --stop /dev/md1
qemu-nbd -d /dev/nbd0
qemu-nbd -d /dev/nbd1
qemu-nbd -d /dev/nbd2
qemu-nbd -d /dev/nbd3
# run step 2 again

创建新的 mdadm 阵列注意您必须找到正确的顺序（更改 3,2,1,0），我能够通过 mdadm --examine /dev/sdx4 按Device Role字段找到（不受影响的 2 个驱动器）。
（感谢@Nikita Kipriyanov 指出）

# Note you must use --assume-clean to avoid mdadm to destroy the data inside old array
# mdadm --create -e1.2  --chunk=64 /dev/md1 --assume-clean --raid-devices=4 --level=5  /dev/nbd{3,2,1,0}
mdadm: /dev/nbd3 appears to be part of a raid array:
       level=raid0 devices=2 ctime=Sun May 14 05:51:00 2023
mdadm: /dev/nbd2 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sun Jun 11 06:56:51 2017
mdadm: /dev/nbd1 appears to be part of a raid array:
       level=raid0 devices=2 ctime=Sun May 14 05:51:00 2023
mdadm: /dev/nbd0 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sun Jun 11 06:56:51 2017
mdadm: largest drive (/dev/nbd3) exceeds size (2925677568K) by more than 1%
Continue creating array? y

0 和第 2 个驱动器意外重新初始化，因此我使用旧配置（--chunk=64）bd20030 4 强制重新创建一个新阵列。新的我有 /dev/md1，假设它没有 lvm，没有分区表，里面只有一个 EXT4 fs。（通过在新驱动器上创建新的 NAS 操作系统来了解）
正在搜索 ext4 超级块备份。

# hexdump /dev/md1 | awk '$6 == "ef53"'
7ce0030 9bf5 6460 006b ffff ef53 0000 0001 0000
bd20030 af1c 6460 0000 ffff ef53 0000 0001 0000
11c7b550 ef20 0012 ffff ffff ef53 0012 0000 0000
1347b550 ef20 0012 ffff ffff ef53 0012 0000 0000
17d20030 9bf5 6460 006b ffff ef53 0000 0001 0000
23d20030 af1c 6460 0000 ffff ef53 0000 0001 0000
37ce0030 9bf5 6460 006b ffff ef53 0000 0001 0000
3bd20030 af1c 6460 0000 ffff ef53 0000 0001 0000
47d20030 9bf5 6460 006b ffff ef53 0000 0001 0000
53d20030 af1c 6460 0000 ffff ef53 0000 0001 0000
6bd20030 af1c 6460 0000 ffff ef53 0000 0001 0000
95395060 ef52 e732 fffd ffff ef53 e731 5f5f 5757

注意，两个 ext4 fs 超级块的偏移量不同，我们只需要旧的，通过 dumpe2fs 进行验证

# dumpe2fs -o superblock=$(((0xbd20030-0x30)/4096)) /dev/md1
dumpe2fs 1.46.2 (28-Feb-2021)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d9b5ac42-4475-48a8-96df-06160027df6e
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         unsigned_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              213381120
Block count:              1707027200
Reserved block count:     786427
Free blocks:              1693513458
Free inodes:              213381109
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
RAID stride:              16
RAID stripe width:        32
Flex block group size:    16
Filesystem created:       Sun May 14 05:51:01 2023
Last mount time:          n/a
Last write time:          Sun May 14 05:51:24 2023
Mount count:              0
Maximum mount count:      -1
Last checked:             Sun May 14 05:51:01 2023
Check interval:           0 (<none>)
Lifetime writes:          145 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      5a21e3a8-b017-4b15-8be1-e537bd99cfe3
Journal backup:           inode blocks
Journal superblock magic number invalid!

注意该Filesystem created字段，如果是你不小心格式化的时候，那么这不是你要找的超级块。发现 magicbyte 之前的 2 个字节是旧的，006b新的是的0000。

过滤正确的签名后，结果更有意义。

# hexdump /dev/md1 | awk '$6 == "ef53" && $4 == "006b"'
7d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
17d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
27d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
37d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
47d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
c7d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
d7d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
187d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
287d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
3e7d00030 9bf5 6460 006b ffff ef53 0000 0001 0000

如果我与普通 EXT4 布局进行比较，它们具有与普通 ext4 相同的相对位置。

md1 上的超级块	+偏移=	正常 EXTT4 超级块
未找到	+0x300000	0000430
7d00030	+0x300000	8000030
17d00030	+0x300000	18000030
27d00030	+0x300000	28000030
37d00030	+0x300000	38000030
47d00030	+0x300000	48000030
c7d00030	+0x300000	c8000030
d7d00030	+0x300000	d8000030
187d00030	+0x300000	88000030
287d00030	+0x300000	e8000030
3e7d00030	+0x300000	98000030

看起来第一个 0x2ffbd0+0x430 = 0x300000 字节 = 3MB 被截断了。不确定为什么 3MB 被截断了，我猜 3 Mb 是每个 mdadm 成员的头 [3（数据成员）* 1M（mdadm 头）]，所以 3MB 被新创建的阵列占用，可能是磁盘上的分区表也有问题。

3MB 的偏移可能是由于错误造成的data offset？ https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm

These superblocks also define a "data offset". This is the gap between the start of the device, and the start of the data. This means that v1.2 must always have at least 4K per device, although it's normally several megabytes. This space can be used for all sorts of things, typically the write-intent bitmap, the bad blocks log, and a buffer space when reshaping an array. It is usually calculated automatically, but can be over-ridden.

在块前添加 3 MB，这样我就可以得到原始文件系统的正确位置。

# dd if=/dev/zero of=/root/header bs=1M count=$((3+2)) # 1M mdadm header for each mdadm member block
# losetup /dev/loop13 /root/header
# mdadm --create /dev/md111 --level=linear  --assume-clean --raid-devices=2 /dev/loop13 /dev/md1
# hexdump /dev/md1 | awk '$6 == "ef53" && $5 == "ffff" && $4 == "006b"'
8000030 9bf5 6460 006b ffff ef53 0000 0001 0000
18000030 9bf5 6460 006b ffff ef53 0000 0001 0000
28000030 9bf5 6460 006b ffff ef53 0000 0001 0000
38000030 9bf5 6460 006b ffff ef53 0000 0001 0000
48000030 9bf5 6460 006b ffff ef53 0000 0001 0000
c8000030 9bf5 6460 006b ffff ef53 0000 0001 0000
d8000030 9bf5 6460 006b ffff ef53 0000 0001 0000
88000030 9bf5 6460 006b ffff ef53 0000 0001 0000
e8000030 9bf5 6460 006b ffff ef53 0000 0001 0000

仅缺少第一个超级块，现在很容易修复。

# e2fsck -p -b $(((0x8000030-0x30)/4096)) /dev/md111
/dev/md111: Superblock needs_recovery flag is clear, but journal has data.
/dev/md111: Recovery flag not set in backup superblock, so running journal anyway.
/dev/md111: recovering journal
/dev/md111: Resize inode not valid.

/dev/md111: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
# mount -o ro /dev/md111 /mnt

挂载时没有错误消息，文件系统结构仍然存在。我打开一些文件并播放视频，没有发现任何问题（目前）。

參考文獻：
https://raid.wiki.kernel.org/index.php/Advanced_data_recovery https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Layout

Answer

总结
仅当您覆盖了不同的 RAID 配置/文件系统（因为备份超级块位置不同，旧超级块不会被覆盖）并且旧文件系统是 EXT4/3 时才有效。并且没有物理损坏。恢复的关键是备份超级块存在。

如果只有 EXT4 的第一部分损坏，应该可以用此方法恢复其文件结构

情况：4 个 RAID 5 驱动器中的 2 个被覆盖了其标头（通过重新初始化新 raid 并在其中创建新的 ext4），另外 2 个保持不变。

首先备份，或者将这 4 个驱动器以只读方式安装在 PC 上。对我来说，旧的 raid 是 /dev/sd{b,c,d,e}4。

blockdev --setro /dev/sd{b,c,d,e}4 # check the device using lsblk

为它们设置覆盖块设备（@Nikita Kipriyanov 提到，它确实使操作更加高效）

modprobe nbd
apt update && apt install qemu-utils -y
# create tmp file to hold changes
qemu-img create -f qcow2 -b /dev/sdb4 -F raw /tmp/sdb4.qcow2
qemu-img create -f qcow2 -b /dev/sdc4 -F raw /tmp/sdc4.qcow2
qemu-img create -f qcow2 -b /dev/sdd4 -F raw /tmp/sdd4.qcow2
qemu-img create -f qcow2 -b /dev/sde4 -F raw /tmp/sde4.qcow2
# mount nbd[1-4] as an overlay device of `/dev/sd[bcde]4`
qemu-nbd -c /dev/nbd0 /tmp/sdb4.qcow2 
qemu-nbd -c /dev/nbd1 /tmp/sdc4.qcow2 
qemu-nbd -c /dev/nbd2 /tmp/sdd4.qcow2 
qemu-nbd -c /dev/nbd3 /tmp/sde4.qcow2

你可以通过重新创建 nbd 设备重新开始

mdadm --stop /dev/md1
qemu-nbd -d /dev/nbd0
qemu-nbd -d /dev/nbd1
qemu-nbd -d /dev/nbd2
qemu-nbd -d /dev/nbd3
# run step 2 again

创建新的 mdadm 阵列注意您必须找到正确的顺序（更改 3,2,1,0），我能够通过 mdadm --examine /dev/sdx4 按Device Role字段找到（不受影响的 2 个驱动器）。
（感谢@Nikita Kipriyanov 指出）

# Note you must use --assume-clean to avoid mdadm to destroy the data inside old array
# mdadm --create -e1.2  --chunk=64 /dev/md1 --assume-clean --raid-devices=4 --level=5  /dev/nbd{3,2,1,0}
mdadm: /dev/nbd3 appears to be part of a raid array:
       level=raid0 devices=2 ctime=Sun May 14 05:51:00 2023
mdadm: /dev/nbd2 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sun Jun 11 06:56:51 2017
mdadm: /dev/nbd1 appears to be part of a raid array:
       level=raid0 devices=2 ctime=Sun May 14 05:51:00 2023
mdadm: /dev/nbd0 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sun Jun 11 06:56:51 2017
mdadm: largest drive (/dev/nbd3) exceeds size (2925677568K) by more than 1%
Continue creating array? y

0 和第 2 个驱动器意外重新初始化，因此我使用旧配置（--chunk=64）bd20030 4 强制重新创建一个新阵列。新的我有 /dev/md1，假设它没有 lvm，没有分区表，里面只有一个 EXT4 fs。（通过在新驱动器上创建新的 NAS 操作系统来了解）
正在搜索 ext4 超级块备份。

# hexdump /dev/md1 | awk '$6 == "ef53"'
7ce0030 9bf5 6460 006b ffff ef53 0000 0001 0000
bd20030 af1c 6460 0000 ffff ef53 0000 0001 0000
11c7b550 ef20 0012 ffff ffff ef53 0012 0000 0000
1347b550 ef20 0012 ffff ffff ef53 0012 0000 0000
17d20030 9bf5 6460 006b ffff ef53 0000 0001 0000
23d20030 af1c 6460 0000 ffff ef53 0000 0001 0000
37ce0030 9bf5 6460 006b ffff ef53 0000 0001 0000
3bd20030 af1c 6460 0000 ffff ef53 0000 0001 0000
47d20030 9bf5 6460 006b ffff ef53 0000 0001 0000
53d20030 af1c 6460 0000 ffff ef53 0000 0001 0000
6bd20030 af1c 6460 0000 ffff ef53 0000 0001 0000
95395060 ef52 e732 fffd ffff ef53 e731 5f5f 5757

注意，两个 ext4 fs 超级块的偏移量不同，我们只需要旧的，通过 dumpe2fs 进行验证

# dumpe2fs -o superblock=$(((0xbd20030-0x30)/4096)) /dev/md1
dumpe2fs 1.46.2 (28-Feb-2021)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d9b5ac42-4475-48a8-96df-06160027df6e
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         unsigned_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              213381120
Block count:              1707027200
Reserved block count:     786427
Free blocks:              1693513458
Free inodes:              213381109
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
RAID stride:              16
RAID stripe width:        32
Flex block group size:    16
Filesystem created:       Sun May 14 05:51:01 2023
Last mount time:          n/a
Last write time:          Sun May 14 05:51:24 2023
Mount count:              0
Maximum mount count:      -1
Last checked:             Sun May 14 05:51:01 2023
Check interval:           0 (<none>)
Lifetime writes:          145 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      5a21e3a8-b017-4b15-8be1-e537bd99cfe3
Journal backup:           inode blocks
Journal superblock magic number invalid!

注意该Filesystem created字段，如果是你不小心格式化的时候，那么这不是你要找的超级块。发现 magicbyte 之前的 2 个字节是旧的，006b新的是的0000。

过滤正确的签名后，结果更有意义。

# hexdump /dev/md1 | awk '$6 == "ef53" && $4 == "006b"'
7d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
17d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
27d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
37d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
47d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
c7d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
d7d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
187d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
287d00030 9bf5 6460 006b ffff ef53 0000 0001 0000
3e7d00030 9bf5 6460 006b ffff ef53 0000 0001 0000

如果我与普通 EXT4 布局进行比较，它们具有与普通 ext4 相同的相对位置。

md1 上的超级块	+偏移=	正常 EXTT4 超级块
未找到	+0x300000	0000430
7d00030	+0x300000	8000030
17d00030	+0x300000	18000030
27d00030	+0x300000	28000030
37d00030	+0x300000	38000030
47d00030	+0x300000	48000030
c7d00030	+0x300000	c8000030
d7d00030	+0x300000	d8000030
187d00030	+0x300000	88000030
287d00030	+0x300000	e8000030
3e7d00030	+0x300000	98000030

看起来第一个 0x2ffbd0+0x430 = 0x300000 字节 = 3MB 被截断了。不确定为什么 3MB 被截断了，我猜 3 Mb 是每个 mdadm 成员的头 [3（数据成员）* 1M（mdadm 头）]，所以 3MB 被新创建的阵列占用，可能是磁盘上的分区表也有问题。

3MB 的偏移可能是由于错误造成的data offset？ https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm

These superblocks also define a "data offset". This is the gap between the start of the device, and the start of the data. This means that v1.2 must always have at least 4K per device, although it's normally several megabytes. This space can be used for all sorts of things, typically the write-intent bitmap, the bad blocks log, and a buffer space when reshaping an array. It is usually calculated automatically, but can be over-ridden.

在块前添加 3 MB，这样我就可以得到原始文件系统的正确位置。

# dd if=/dev/zero of=/root/header bs=1M count=$((3+2)) # 1M mdadm header for each mdadm member block
# losetup /dev/loop13 /root/header
# mdadm --create /dev/md111 --level=linear  --assume-clean --raid-devices=2 /dev/loop13 /dev/md1
# hexdump /dev/md1 | awk '$6 == "ef53" && $5 == "ffff" && $4 == "006b"'
8000030 9bf5 6460 006b ffff ef53 0000 0001 0000
18000030 9bf5 6460 006b ffff ef53 0000 0001 0000
28000030 9bf5 6460 006b ffff ef53 0000 0001 0000
38000030 9bf5 6460 006b ffff ef53 0000 0001 0000
48000030 9bf5 6460 006b ffff ef53 0000 0001 0000
c8000030 9bf5 6460 006b ffff ef53 0000 0001 0000
d8000030 9bf5 6460 006b ffff ef53 0000 0001 0000
88000030 9bf5 6460 006b ffff ef53 0000 0001 0000
e8000030 9bf5 6460 006b ffff ef53 0000 0001 0000

仅缺少第一个超级块，现在很容易修复。

# e2fsck -p -b $(((0x8000030-0x30)/4096)) /dev/md111
/dev/md111: Superblock needs_recovery flag is clear, but journal has data.
/dev/md111: Recovery flag not set in backup superblock, so running journal anyway.
/dev/md111: recovering journal
/dev/md111: Resize inode not valid.

/dev/md111: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
# mount -o ro /dev/md111 /mnt

挂载时没有错误消息，文件系统结构仍然存在。我打开一些文件并播放视频，没有发现任何问题（目前）。

參考文獻：
https://raid.wiki.kernel.org/index.php/Advanced_data_recovery https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Layout

意外将最后 2 个驱动器重新初始化为 RAID0 后恢复 4 个驱动器 RAID5 阵列

答案1

如果您没有多余的空间资源来存储至少两倍于阵列原始大小的数据，例如，如果您没有至少 3 TB * 4 个驱动器 * 2 = 24 TB 的可用空间用于恢复操作，请停止并将整个工作交给专业的数据恢复服务。

答案2

相关内容