![恢复使用完整磁盘构建的mdadm raid1(覆盖分区数据)](https://linux22.com/image/217510/%E6%81%A2%E5%A4%8D%E4%BD%BF%E7%94%A8%E5%AE%8C%E6%95%B4%E7%A3%81%E7%9B%98%E6%9E%84%E5%BB%BA%E7%9A%84mdadm%20raid1%EF%BC%88%E8%A6%86%E7%9B%96%E5%88%86%E5%8C%BA%E6%95%B0%E6%8D%AE%EF%BC%89.png)
在设置我的新 PC 时,我还设置了一个新的 RAID 1,其中包含 2 个驱动器,LUKS 位于顶部。将所有数据复制到其中后,我确保一切都可用,然后粉碎了旧驱动器。
但现在我已经没有RAID了。我发现这很可能是因为我在创建 RAID 时使用完整磁盘而不是使用分区。有什么办法可以恢复RAID并恢复其中的数据吗?我已经保存了用于创建 RAID 的确切命令,但在确定不会不可逆转地搞砸某些事情之前我不想做任何事情。
fdisk -l
两个驱动器的输出:
Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EFAX-68J
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 068E27EE-055B-A24A-B51B-D0B79E3DEA00
Disk /dev/sdc: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: TOSHIBA HDWD130
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F4ADCB83-B715-9B4A-A6A0-96687568611E
RAID 是使用以下命令创建的:
sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
mdadm --examine
两个磁盘的输出相同:
/dev/sdb:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sdc:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
所以看起来分区数据已被删除,这就是为什么它不再作为 raid 成员可见(类型 fd)。是否可以重写分区数据并重新启动RAID?
我的行mdadm.conf
如下:
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=WORKSTATION:0 UUID=fe2547a6:3296c156:303989ac:febb5051 devices=/dev/sdb,/dev/sdc
我是否可以仅用 1 个成员启动 RAID 并以这种方式恢复数据?两个磁盘上的 LUKS 数据头应该相同,对吗?或者我应该在再次覆盖它们之前备份它们?
我非常感谢您的帮助,在失败之前大约有 1500GB 的数据。
PS 我知道这 2 个磁盘的大小不同,它曾经是 2 个 3TB 驱动器,但其中一个出现故障,所以我将其替换为 4TB 驱动器。在此情况发生之前,RAID 已经工作并且完全同步。
答案1
由于RAID 1是一个简单的镜像,因此您可以忽略RAID问题,直接搜索LUKS标头。如果不涉及分区,它应该位于驱动器开头附近的某个位置。可能有几百 MiB 偏移,因为mdadm
使用了相当大的数据偏移。
以下命令搜索驱动器的前 1 GiB:
# hexdump -C -n 1G /dev/sdx | grep LUKS
08100000 4c 55 4b 53 ba be 00 02 00 00 00 00 00 00 40 00 |LUKS..........@.|
在此示例中,偏移量 0x8100000 (129 MiB) 处存在潜在的 LUKS 标头。
在此偏移处创建一个(只读)循环设备并查看它是否有效......
# losetup --find --show --read-only --offset $((0x8100000)) /dev/sdx
/dev/loop2
# cryptsetup luksOpen /dev/loop2 lukstest
Enter passphrase:
# mount -o loop,ro /dev/mapper/lukstest /mnt/somewhere
如果有效,您可以尝试在保持数据不变的情况下进行恢复。但无论如何,我建议您先制作完整备份副本。
是否可以重写分区数据并重新启动raid?
理论上,你必须
- 创建两个循环设备(*),偏移量1 MiB(未来分区偏移量)
- 在循环设备上再次运行上面的 hexdump 命令以确定正确的偏移量(与裸驱动器相比应为 -1 MiB),
- 使用这些循环设备,使用正确的偏移量重新创建 RAID并相应地调整 mdadm.conf,
cryptsetup open
突袭,- 稍微缩小文件系统,为磁盘末尾的 GPT 备份标头腾出空间,
- 卸载文件系统(如果已安装),
cryptsetup close
luks,mdadm --stop
raid,losetup -d
分离循环设备, - 在两个驱动器上创建偏移量为 1 MiB 的分区
此时,您应该拥有带分区的驱动器、分区上的 raid、raid 上的 luks、luks 内的文件系统。
然而,这是最佳情况,只有当我正确理解你的情况时,它才会这样工作。有很多方法会导致这种情况完全错误。
(*)
使用循环设备进行跳环是必要的,因为您必须先缩小文件系统,然后才能在不损坏设备末尾的情况下创建分区。并且只有当您的 RAID 正在运行时(如果它在两个驱动器上运行并且必须保持一致性),您才能缩小文件系统。
如果您直接创建分区,可能不会发生任何可怕的事情(或者无论如何它已经发生了),但从技术上讲,在这种情况下,这不是从裸磁盘到分区的正确方法。
答案2
解决了!
由frostschutz提供的答案非常有效,我目前正在将所有数据备份到另一个磁盘。
如果您碰巧通过谷歌或其他搜索引擎偶然发现这个问题。尝试使用frostschutz提供的步骤找到LUKS标题,如果你找不到任何东西,最好发布你自己的问题,但这会变得相当困难。
对于在 mdadm raid 中使用完整磁盘,我强烈建议首先创建分区。如果你非常清楚自己在做什么能工作,但如果重复使用磁盘,它可能会在磁盘末尾有一个备份表,根据 UEFI 标准,该备份表将用于覆盖您的“错误”分区表(请参阅关于这HN 文章)
可以使用 和 的组合来完全清除所有分区信息sgdisk --zap
,wipefs -a
但不要让自己头痛,也不要犯我犯的同样的错误。