☰

新电脑中的 Luks 卷损坏了标头？

tag-icon • tag-icon linux raid luks
新电脑中的 Luks 卷损坏了标头？

我将数据备份到 raid1 中的 Luks 卷上（首先是 raid 1 中的 2 个光盘，其次是 Luks）

我将 2 个驱动器移至新服务器中，但它们停止工作。在轻微的恐慌发作后，我搜索了更多信息，一些网站建议使用 Hexdump 来检查标头的内容。但很多网站都不太清楚它在哪里。谁能告诉我我的数据是否可以恢复或者发生了什么？

我所做的只是将它们转移到一台新电脑上。无需安装。没有命令，没有什么奇怪的。插入具有现有操作系统的计算机并启动它。

sudo hexdump -Cvs 0 -n 2000 /dev/sdb

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001c0  01 00 ee fe ff ff 01 00  00 00 ff ff ff ff 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  53 16 20 86 00 00 00 00  01 00 00 00 00 00 00 00  |S. .............|
00000220  af be c0 d1 01 00 00 00  00 08 00 00 00 00 00 00  |................|
00000230  8e be c0 d1 01 00 00 00  e1 8a 60 b4 82 6f 50 42  |..........`..oPB|
00000240  93 ea db 27 34 ec a7 5b  02 00 00 00 00 00 00 00  |...'4..[........|
00000250  80 00 00 00 80 00 00 00  86 d2 54 ab 00 00 00 00  |..........T.....|

raid 是使用以下命令创建的：（经过编辑以匹配驱动器名称）

sudo mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2 /dev/sdp /dev/sdb

lsblk 显示：

sdb                         8:16   0   3.7T  0 disk
sdp                         8:240   0   3.7T  0 disk

fdisk -l /dev/sdb

Disk /dev/sdb: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: EFRX-68WT0N0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B4608AE1-6F82-4250-93EA-DB2734ECA75B

另外需要澄清的是，我将它们返回到原来的机器，但它们仍然无法识别。 mdadm 显示他们不是 raid 成员。甚至

mdadm--组装--扫描

什么也没做

答案1

哈扎！弄清楚了！

因此，当我将硬盘放入新电脑时，不知何故，它们以某种方式获得了新的映射/块大小或其他东西，不知道。

我破产了，做了一个

sudo hexdump -s 0 -n 1000000000 -C /dev/sdb | grep LUKS

这将在第一个 GB 中搜索短语 LUKS

结果发现：

08000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|

接下来我创建了一个到该偏移量的环回：

sudo losetup -o 0x08000000 -r -f /deb/sdb

现在列出我的环回，我可以看到：

sudo losetup -a
/dev/loop8: [0006]:659 (/dev/sdb), offset 134217728

现在让我们打开安装座，祈祷吧

sudo cryptsetup luksOpen /dev/loop8 luksrecover

然后……它打开了！

常用的安装命令并重新开始工作！定义。备份该标头。我会复制我的数据并重新格式化驱动器，然后将其放回去仍然不知道为什么会发生这种情况。

答案2

您的十六进制转储显示块 #0 (00000000 - 000001ff) 和块 #1 (00000200+) 的开始部分。

在 000001fe 处，值为 0xaa55（小端）。块 #0 中的内容是 MBR 分区表存在的基本指示。第一个（在本例中是唯一的）主分区条目将位于 000001be - 000001cd，即：

000001b0  .. .. .. .. .. .. .. ..  .. .. .. .. .. .. 00 00  |................|
000001c0  01 00 ee fe ff ff 01 00  00 00 ff ff ff ff .. ..  |................|

这将解码为类型为 0xee 的非活动分区，从 LBA 0x00000001 开始，长度为 0xffffffff。由于这比 CHS 字段可以表示的要大，因此可以忽略分区开始/结束 CHS 字段。

分区类型0xee表明这是 GPT保护性MBR，所以这个 MBR 分区表应该被完全忽略，并且真正的GPT分区表从 LBA #1 开始。

从十六进制转储中的 00000228 开始是 GPT 标头字段first usable LBA，其值为 0x00000000 00000800，即块 2048。将其乘以 512 字节的块大小，您将得到 0x100000 或 1048576，这是典型的 1MiB磁盘。这与您找到的偏移量（134217728 = 128 MiB 到磁盘中）不匹配，因此磁盘上可能在 LUKS 分区之前存在一些非 LUKS 分区。不幸的是，GPT 分区条目保存在块#2 和后续块（如果需要）中，因此您的十六进制转储不允许检查其有效性。

GPT 标头中的字段last usable LBA的值为 0x01d1c0be8e = 7814037134，位于转储中的偏移量 00000230 处。这比 报告的磁盘大小小 34 个块fdisk，这看起来是正确的：在磁盘末尾，有 33 个块的空间用于备份 GPT 标头块和 32 个分区条目块，+1 表示该块编号从块 #0 开始，而不是从 #1 开始。

这似乎在分区空间之外没有为 RAID 元数据区域留下任何空间。

您绝对确定 RAID 是使用整个磁盘设备而不是分区设备创建的吗？换句话说，也许是这样的

sudo mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2 /dev/sdp2 /dev/sdb2

而不是：

sudo mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2 /dev/sdp /dev/sdb

如果在创建 RAID 阵列后，您使用类似fdisk /dev/sdb或 之类的东西fdisk /dev/sdp对磁盘进行分区，GPT 分区表将覆盖 RAID 元数据...并且在重新启动后，您将不再拥有 RAID，而只是一个普通的 GPT 分区磁盘（第二个磁盘现在未使用，并且很快与第一个磁盘失去同步）。

还有一种可能是固件可能已经擦除了您的 RAID 元数据（或这里），或者返回旧系统，或者将磁盘移至新系统时。

基本上，系统上的 UEFI 固件对 Linux 软件 RAID 没有任何了解，但它肯定能理解 GPT 分区表。当固件发现磁盘开头有 GPT 主分区表，但备份分区表似乎并不完全位于磁盘末尾（因为 RAID 元数据以元数据格式 1.0 及以下格式存储在那里）时，某些 UEFI固件将通过增加last usable LBA主 GPT 中的值并将备份 GPT 重新写入磁盘的真实末尾来“修复”此问题，从而覆盖 RAID 元数据。

这个“修复”显然是 UEFI 固件的事情应该根据 UEFI 规范执行此操作。对于企业 SAN 管理员调整 LUN 大小来说很方便，但对于全磁盘软件 RAID 实施来说却很麻烦。

同样，如果您使用软件 RAID 元数据格式 1.1 或更高版本（将 RAID 元数据放在磁盘的开头），固件将检测到备份GPT并用它来重建“丢失的”主 GPT...再次踩踏 RAID 元数据。

如果您确实拥有全磁盘级别的功能软件 RAID，以及 RAID 内的分区那么您的加密 LUKS 卷将具有必须已经是类似/dev/md/d5p2或 的东西/dev/md_d5p2。

如果现在在主 GPT 之后但在第一个分区开始之前存在未分配的空间，则可能意味着您使用的是 RAID 元数据格式 1.1 或更高版本，并且固件通过将主 GPT 从 RAID 元数据之后的位置移动到磁盘的真正开始。

同样，如果您的磁盘曾经被分区完全占用，但现在在最后一个分区结束后大约有 64-128K 未分配空间，则表明您使用的是 RAID 元数据格式 1.0 或更早版本，并且固件覆盖了它使用备份 GPT，无论是在原始系统上还是在将磁盘移动到新系统时。

在我看来，GPT 带来了一些新的东西，任何构建软件 RAID 集的人都需要注意。

  • 从（成对的）分区中制作非分区 RAID 集似乎没问题（即/dev/md0从/dev/sdX1和中创建/dev/sdY1，然后/dev/md1从/dev/sdX2和中创建/dev/sdY2，等等）
  • 准备设置全磁盘软件 RAID 时，应注意使用sgdisk --zap或类似工具完全擦除主 GPT 和备份 GPT，以避免基于固件的自动恢复在下次启动时立即覆盖 RAID 元数据。
  • 在 UEFI 系统上细分全磁盘软件 RAID 时，最好使用 GPT 分区以外的其他分区作为下一个更高层（也许使全磁盘 RAID 阵列设备成为 LVM PV？），因为固件可能会检测 RAID 容器内的 GPT 分区表，并在不了解 RAID 层的情况下尝试“修复”“位置错误”的 GPT，从而破坏 RAID 元数据。
  • 这意味着在 UEFI 可启动系统磁盘上使用全磁盘软件 RAID 可能不是一个好主意，因为系统磁盘基本上需要有一个 GPT 分区表和一个 EFI 系统分区，而固件必须能够完全支持这两个分区。了解并访问。

相关内容