使用 dd 克隆 LUKS 加密磁盘时出现意外行为

Question 1

这似乎与使用 USB 底盘测试 3.5 英寸备份硬盘有关。虽然答案与 dd 无关，但如果有人遇到类似的问题，我会发布它。

原始驱动器使用 512 字节扇区，但显然大多数外部 3.5 英寸 USB 机箱使用的芯片组决定 Windows 是任何人都可能想要使用的唯一操作系统。比尔盖茨说扇区是 4K，所以它们必须是 4K。然后它高兴地报告分区的原始扇区起始号。但现在它报告 4K 扇区大小，然后 Linux 将其转换为错误的字节偏移量。它还解释了报告的 14.6T 分区大小。

使用具有正确偏移量的环回设备确实可以挂载和访问分区 --- 尽管我似乎仍然无法访问 LUKS sdb5 分区（因为它没有报告），即使我输入了从原始驱动器上的偏移量计算出的地址。数据在那里，但混乱的报告使 cryptsetup 无法工作。不确定除了获得一个不那么冒昧的 usb 底盘之外是否还有其他解决方法。

将 HDD（通过 sata）插入原始 PC 确实会显示 sdb5 分区。DD 显然按预期工作，甚至复制了磁盘 ID。我的 2.5 英寸 USB 底盘（用于将原始驱动器连接到笔记本电脑）没有同样的问题。要么它不是为 Windows 设计的，要么它只是将 512 的块大小与 SSD 关联起来。无论哪种情况，它都会返回正确的扇区大小，我可以访问 LUKS 分区。

所以……这是一个警示故事，让我们相信即使是最简单的设备也不会试图“纠正”你。在最好的一切世界中，一切都是最好的。

Answer

这似乎与使用 USB 底盘测试 3.5 英寸备份硬盘有关。虽然答案与 dd 无关，但如果有人遇到类似的问题，我会发布它。

原始驱动器使用 512 字节扇区，但显然大多数外部 3.5 英寸 USB 机箱使用的芯片组决定 Windows 是任何人都可能想要使用的唯一操作系统。比尔盖茨说扇区是 4K，所以它们必须是 4K。然后它高兴地报告分区的原始扇区起始号。但现在它报告 4K 扇区大小，然后 Linux 将其转换为错误的字节偏移量。它还解释了报告的 14.6T 分区大小。

使用具有正确偏移量的环回设备确实可以挂载和访问分区 --- 尽管我似乎仍然无法访问 LUKS sdb5 分区（因为它没有报告），即使我输入了从原始驱动器上的偏移量计算出的地址。数据在那里，但混乱的报告使 cryptsetup 无法工作。不确定除了获得一个不那么冒昧的 usb 底盘之外是否还有其他解决方法。

将 HDD（通过 sata）插入原始 PC 确实会显示 sdb5 分区。DD 显然按预期工作，甚至复制了磁盘 ID。我的 2.5 英寸 USB 底盘（用于将原始驱动器连接到笔记本电脑）没有同样的问题。要么它不是为 Windows 设计的，要么它只是将 512 的块大小与 SSD 关联起来。无论哪种情况，它都会返回正确的扇区大小，我可以访问 LUKS 分区。

所以……这是一个警示故事，让我们相信即使是最简单的设备也不会试图“纠正”你。在最好的一切世界中，一切都是最好的。

Question 2

[编辑] 在花费了大量时间起草、修改、查找参考资料、引文并发布此答案后，我感到很尴尬，因为原帖作者已经回答了自己的问题。我最初的想法是删除我的答案，因为其中大部分内容都不相关，但在投入了大量时间却可能毫无结果之后，这仍然很困难。不过我希望解决原帖作者提到的新发现的问题未标记回答。

更新的问题：

使用具有正确偏移量的环回设备确实可以挂载和访问分区 --- 尽管我似乎仍然无法访问 LUKS sdb5 分区（因为它没有报告），即使我输入了从原始驱动器上的偏移量计算出的地址。数据在那里，但混乱的报告使 cryptsetup 无法工作。不确定除了获得一个不那么冒昧的 usb 底盘之外是否还有其他解决方法。

既然它在内部连接时似乎可以工作，而且您已确定问题出在底盘上，那么为什么不重新复制驱动器并更改您的bs值呢？毕竟，当您通过底盘插入原始驱动器时，您可以访问文件，因此它以这种方式被识别。因此，奇怪的是，原始驱动器可以通过底盘读取，但新的副本却不能，除非……

...碰巧我的答案确实适用。那么也许在循环设备场景中，你可以计算与原始驱动器的偏移量，你可以尝试这个脚本确定作为 USB 连接时报告的偏移量，以解决无法识别的分区问题。

否则，更简单但更繁琐的修复方法是在重新复制主驱动器以进行备份之前重新格式化备用驱动器，以便当它作为外部 USB 设备插入时，芯片组不会混淆并导致 Linux 转换不正确的字节偏移量。

[编辑结束]

过时且不适用的过于简单化的解释

发生的情况是，你可能没有格式化你之前用来备份主 Linux 安装的备用磁盘dd，而你主 Linux 安装硬盘上的是MBR 分区备用磁盘有一个GPT 分区方案。

@oldfred已经在评论中指出了这一点，但仍然没有收到对以下命令输出请求的回应

sudo gdisk -l /dev/sdb

（而我已经替换了 X 来表示磁盘在 GPT/MBR 相关错误中的显示方式，也就是笔记本电脑）

因此，当您将dd整个磁盘复制到比原始（或源）磁盘更大的备用磁盘时，因为它确实逐字节复制驱动器，它复制了前一个硬盘的分区方案（包括分区表和标头），并将其放在较大磁盘的 GPT 分区方案之上。这意味着它将被 GPT 的保护性MBR 旨在防止基于 MBR 的磁盘实用程序误识别并可能覆盖 GPT 磁盘的层并与位于设备启动处的 LUKS 标头相冲突，与 Protective MBR 位于同一位置。因此，当不允许写入此部分时，它无法包含正确的标头信息或/dev/sdb5无论/dev/sda5哪种情况。并且，如果您想知道为什么dd在完成时没有将其中任何内容报告为错误或运行该“投诉”，这可能是为什么如果没有完成时显示的输出，我将无法告诉您，dd输出通常如下所示：

6+1 records in
6+1 records out
3454 bytes (3.5 kB) copied, 8.3585e-05 s, 41.3 MB/s

但如果不是这样，如果它提到了，那将是实时报告而不是在最后显示。否则，您可能不得不查看内核日志消息（dmesg、或/var/log/kern.log）以获取更详细的消息，以防它被视为硬件错误。smartctl -x /dev/sda在这种情况下，您可能也会发现它很有用，因为它可能是在开始分区之前写入某个部分的内容，也可能显示在内核日志中。特别是因为这个错误直到之后才被报告：

发现无效的 GPT 和有效的 MBR；将内存中的 MBR 转换为 GPT 格式。

由于这个“过于简单的答案”变得越来越复杂，我离题了，不会费心去讨论这一切是如何运作的具体冲突MBR 磁盘分区相对GPT 分区表头和GPT 分区条目以及 BIOS、UEFI 或具有 CSM 条件的 UEFI 对此有何影响，以进一步也许没有必要“为什么”可能超出了如何解决你的问题的范围，但希望能提供一定程度的见解。

为了将来解决这个问题，您可以在连接到笔记本电脑之前检查备份映像一致性，以检查备份副本是否存在任何问题

fsck -y /dev/sdb

这让我想起，当dd“无任何抱怨”地完成时，实时启动棒系统是否能够看到第三个分区？因为如果可以，是否有人尝试从那里访问您的数据？如果两个问题的答案都是肯定的，那么我刚才的想法可能就失效了，也就是说你的硬盘驱动器外壳的控制器可能是嫌疑犯。

啊，好吧……

下一步——备份您的数据

取决于你的最终目标是什么，无论是：

要备份您的只是保存您的数据，以便在尝试修复主 PC 时数据不会丢失，修复完成后您只需将数据复制回 PC 即可；或者
如果要创建主 PC 的精确副本，那么如果您在修复“损坏的安装”时搞砸了，您可以从头开始

那么，您可能希望如何进行将有所不同。这里推断和/或需要假设的主要区别是，对于上述每种情况，分别在以下情况下：

如果所有其他方法都失败了，您将不得不重新安装所需的操作系统，并通过将其安装为外部或内部驱动器来复制数据，并且仅限于个人文件，因此任何应用程序、软件包、程序或设置都需要重新下载、重新安装；或重置（更多工作 - 文件数据独家恢复）
如果一切都失败了，你可以继续尝试并从现在的位置重新开始，这样你的系统就可以重新启动，而不需要重新安装任何东西或复制任何东西（更多尝试-完全系统恢复）

既然你提到你是“在确定可以访问备份磁盘上的数据之前，犹豫不决“，我假设你只是想在修复 PC 时备份数据，并假设fdiskas输出中提到的扩展分区/dev/sda2不包含任何需要保留的数据，并且这只与/dev/sda5它有关，因为它被提及

...但是没有 /dev/sdb5 我就无法挂载 LUKS 加密卷，也无法访问我的数据。

然后，我建议您更改您的选项和标志，dd这样就不会通过将整个磁盘直接复制到备用磁盘来备份整个磁盘，而是通过更改指向保存在已安装备用磁盘上的映像文件来制作整个磁盘的备份映像副本of，dd然后您可以将该映像虚拟安装为虚拟系统，以避免备用驱动器上的任何分区冲突，或者更好的是，更改标志if并dd仅复制您需要的分区，如果/dev/sda5使用安装两个磁盘并从实时系统启动时引用的命名方案。

由于您在复制磁盘时没有使用oflag=direct或选项，因此我强烈建议您查看oflag=syncdd 手册页如果执行上述操作，则可选择以下选项。

解答你的疑问

我的理解是 dd 会复制每个字节，并且不会遗漏任何隐藏的元数据，但我不是现代磁盘控制器方面的专家。我遗漏了什么吗（除了 /dev/sdb5）？

是的，你说得对，但正如我们所发现的，如果没有正确记录隐藏元数据，可能会忽略一些小的写入错误。因为它读取得很好，只是不能写入。因此，虽然很难量化你遗漏了什么，因为你似乎已经知道了不少，但我至少要简单提一下，它会逐字节dd复制每个位，甚至复制未分区空间的空白或 NULL 字节，甚至复制未标记的“空白空间”，文件曾经存在但被删除，可以恢复，因此如果使用“dd”的副本包含该“空白空间”，则可以恢复。但它所做的远不止简单地读取stdin和输出，stdout尽管它需要合并一些选项，但我离题了。

如果有的话，我敢说大多数人可能经常忘记考虑的事情是复制每个字节的实际含义或翻译，这取决于场景和从中复制/读取的内容或使用保存数据的介质，例如与被复制的源在大小或类型上不相似的设备。详细说明这一点的一个具体参考是，如果它不能被读取，dd它就不能被写入dd。因此，在将文件系统从一个驱动器复制到几乎或完全相似的驱动器方面，某些硬件级别编码的数据将不会被转移，而依赖于硬件寻址的其他数据的信息位未存储在文件或设备本身中，这些信息将不会改变。但对一些人来说，这是显而易见的，而对另一些人来说则不是。可以肯定的是，如果它存在于一个块上并且可以被计算机读取但不向用户显示，那么它就可以被复制。

我需要在笔记本电脑上做些什么吗？如果它是原始密码的真正字节克隆，则密码应该相同。

正如我们现在所推测的，问题不是笔记本电脑造成的，而是数据被复制到不匹配的硬件和不匹配的分区方案上（但后者更重要，后面会解释），导致分区无法被操作系统识别，从而导致无法挂载。至于密码相同，是的，你是对的，密码是一样的。

更进一步来说，正如LUKS 常见问题在下面1.2 警告 - 克隆/成像：

如果您克隆或镜像 LUKS 容器，则会复制 LUKS 标头，并且主密钥将保持不变！这意味着，如果您将映像分发到多台机器，则无论您是否更改密码，所有机器都将使用相同的主密钥。

是的，你是对的，它是一样的。但你的问题不是它无法识别密码，而是分区本身。

更详细的解释（不太技术性）

虽然在检查错误消息后，分区方案不匹配被列为问题的嫌疑人，但该结论源于许多被认为适用的经验，但与它们有关的细节被省略，可能是因为它们与问题的产生似乎无关。这些考虑因素包括：

了解主 Linux 系统 SSD 的分区方案，确定其具有 MBR 分区方案，因为提到这/dev/sda2是一个扩展分区，并且仅存在于 MBR 中。缺少的确凿证据是 PC 是在 BIOS/Legacy 中运行，还是在支持 CSM 的 UEFI 中运行
由于不知道主板的 BIO 或 UEFI 设置，我们不知道实时启动棒是在传统模式还是 UEFI 模式下启动的，但它必须与桌面相匹配，才能在连接时识别两个磁盘。不过，我们无法定义“被识别”，因为要对每个字节进行正确的复制，需要离线复制，这意味着您不会安装它们来查看是否真的可以访问它们。但我们也不知道使用什么系统进行复制，也不知道使用了dd哪个版本的dd
确定备用硬盘的分区方案 - 关于备用硬盘的来源、格式、来源（如果是 Linux PC 或 Windows PC）的信息并不多，这些信息将极大地帮助确定写入的数据的目的地（发现错误的地方）
最后，我们知道笔记本电脑在备份之前可以看到驱动器，因此如果运行 UEFI 或以 BIOS 模式启动，它必须具有 CSM 支持。当它能够访问备份的前 2 个分区但看不到第 3 个 luks 加密分区时，可以推断这与 OS 系统识别无关，而是缺少分区头信息导致无法查看驱动器。

附加说明和注意事项

一些琐碎的注释可以帮助你将来更有效地获得帮助或找到答案，请随意接受或拒绝，因为我只提供它们作为建议，而不是任何形式的批评或嘲笑，因为我相信任何人都可以同样从这篇文章中指出我的错误（意思是说我并不比你好），恕我直言：

如果您还不知道，“分区”和“卷”通常不能互换，从技术上讲，它们是指硬盘的不同存储单元。而卷是具有单个文件系统的单个可访问存储区域。分区是硬盘的逻辑分区。虽然这可能只是本文的语义问题，但在尝试理解所发生的事件时，它可能有助于在其他场景中减少误解
请尽量保持参考的一致性，您显示的fdisk输出指示/dev/sda1 /dev/sda2和，/dev/sda5但随后提到使用cryptsetup我/dev/s**d**b5理解设备位置随每个系统而变化，但它可能会对您具体尝试的内容造成混淆，例如什么、何时和何地。即看到如何fdisk显示/dev/sda上下文的分区我可以假设这是在笔记本电脑上运行的，当您提到命令时dd，通过输入标志（或if=）判断我可以假设它是源磁盘，但如果我根据提供的信息假设它cryptsetup是在与 fdisk 中引用的相同驱动器上运行的，dd那么它必须在不同的系统上才能具有不同的设备分配。相反，如果我假设它是笔记本电脑，那么我必须假设发生了某种交换以构成相同的驱动器或者它不是接收设备映射名称更改的相同设备。虽然在这种情况下它可能不那么相关，但在其他情况下它可能意味着一个错误而不是另一个错误。
考虑到上述两点，当您提到源磁盘是 1.8 TB SSD 而目标磁盘是 3TB HDD，但随后显示gdisk5TB 磁盘的输出时，您可能会更加清楚这有多么令人困惑，这表明要么是引用 3 TB 磁盘时出现了拼写错误，要么您的意思是说 HDD 的 3TB 分区，而后者有助于指出由执行命令选项标志而不是其他原因导致的问题。
虽然您提到“我怀疑这很重要”，但在备份时，驱动器的大小和类型非常重要dd。尤其是如果它是重要的数据，不能被视为细微差别，那么最好注意这些事情，因为我会提出可能导致使用后未报告的错误的问题dd（例如仅dmesg在缓冲区膨胀) 如果不是这里所述情况，更具体地说，当您从低容量驱动器传输到高容量驱动器以及从固态驱动器传输到硬盘驱动器时，可以使用有效的选项来dd缓解性能问题、缓存错误以及最终传输数据的可靠性。（虽然我删除了原始的总结，说明所有这些都很重要，因为它无论如何都无法帮助您解决问题）

Answer

[编辑] 在花费了大量时间起草、修改、查找参考资料、引文并发布此答案后，我感到很尴尬，因为原帖作者已经回答了自己的问题。我最初的想法是删除我的答案，因为其中大部分内容都不相关，但在投入了大量时间却可能毫无结果之后，这仍然很困难。不过我希望解决原帖作者提到的新发现的问题未标记回答。

更新的问题：

使用具有正确偏移量的环回设备确实可以挂载和访问分区 --- 尽管我似乎仍然无法访问 LUKS sdb5 分区（因为它没有报告），即使我输入了从原始驱动器上的偏移量计算出的地址。数据在那里，但混乱的报告使 cryptsetup 无法工作。不确定除了获得一个不那么冒昧的 usb 底盘之外是否还有其他解决方法。

既然它在内部连接时似乎可以工作，而且您已确定问题出在底盘上，那么为什么不重新复制驱动器并更改您的bs值呢？毕竟，当您通过底盘插入原始驱动器时，您可以访问文件，因此它以这种方式被识别。因此，奇怪的是，原始驱动器可以通过底盘读取，但新的副本却不能，除非……

...碰巧我的答案确实适用。那么也许在循环设备场景中，你可以计算与原始驱动器的偏移量，你可以尝试这个脚本确定作为 USB 连接时报告的偏移量，以解决无法识别的分区问题。

否则，更简单但更繁琐的修复方法是在重新复制主驱动器以进行备份之前重新格式化备用驱动器，以便当它作为外部 USB 设备插入时，芯片组不会混淆并导致 Linux 转换不正确的字节偏移量。

[编辑结束]

过时且不适用的过于简单化的解释

发生的情况是，你可能没有格式化你之前用来备份主 Linux 安装的备用磁盘dd，而你主 Linux 安装硬盘上的是MBR 分区备用磁盘有一个GPT 分区方案。

@oldfred已经在评论中指出了这一点，但仍然没有收到对以下命令输出请求的回应

sudo gdisk -l /dev/sdb

（而我已经替换了 X 来表示磁盘在 GPT/MBR 相关错误中的显示方式，也就是笔记本电脑）

因此，当您将dd整个磁盘复制到比原始（或源）磁盘更大的备用磁盘时，因为它确实逐字节复制驱动器，它复制了前一个硬盘的分区方案（包括分区表和标头），并将其放在较大磁盘的 GPT 分区方案之上。这意味着它将被 GPT 的保护性MBR 旨在防止基于 MBR 的磁盘实用程序误识别并可能覆盖 GPT 磁盘的层并与位于设备启动处的 LUKS 标头相冲突，与 Protective MBR 位于同一位置。因此，当不允许写入此部分时，它无法包含正确的标头信息或/dev/sdb5无论/dev/sda5哪种情况。并且，如果您想知道为什么dd在完成时没有将其中任何内容报告为错误或运行该“投诉”，这可能是为什么如果没有完成时显示的输出，我将无法告诉您，dd输出通常如下所示：

6+1 records in
6+1 records out
3454 bytes (3.5 kB) copied, 8.3585e-05 s, 41.3 MB/s

但如果不是这样，如果它提到了，那将是实时报告而不是在最后显示。否则，您可能不得不查看内核日志消息（dmesg、或/var/log/kern.log）以获取更详细的消息，以防它被视为硬件错误。smartctl -x /dev/sda在这种情况下，您可能也会发现它很有用，因为它可能是在开始分区之前写入某个部分的内容，也可能显示在内核日志中。特别是因为这个错误直到之后才被报告：

发现无效的 GPT 和有效的 MBR；将内存中的 MBR 转换为 GPT 格式。

由于这个“过于简单的答案”变得越来越复杂，我离题了，不会费心去讨论这一切是如何运作的具体冲突MBR 磁盘分区相对GPT 分区表头和GPT 分区条目以及 BIOS、UEFI 或具有 CSM 条件的 UEFI 对此有何影响，以进一步也许没有必要“为什么”可能超出了如何解决你的问题的范围，但希望能提供一定程度的见解。

为了将来解决这个问题，您可以在连接到笔记本电脑之前检查备份映像一致性，以检查备份副本是否存在任何问题

fsck -y /dev/sdb

这让我想起，当dd“无任何抱怨”地完成时，实时启动棒系统是否能够看到第三个分区？因为如果可以，是否有人尝试从那里访问您的数据？如果两个问题的答案都是肯定的，那么我刚才的想法可能就失效了，也就是说你的硬盘驱动器外壳的控制器可能是嫌疑犯。

啊，好吧……

下一步——备份您的数据

取决于你的最终目标是什么，无论是：

要备份您的只是保存您的数据，以便在尝试修复主 PC 时数据不会丢失，修复完成后您只需将数据复制回 PC 即可；或者
如果要创建主 PC 的精确副本，那么如果您在修复“损坏的安装”时搞砸了，您可以从头开始

那么，您可能希望如何进行将有所不同。这里推断和/或需要假设的主要区别是，对于上述每种情况，分别在以下情况下：

如果所有其他方法都失败了，您将不得不重新安装所需的操作系统，并通过将其安装为外部或内部驱动器来复制数据，并且仅限于个人文件，因此任何应用程序、软件包、程序或设置都需要重新下载、重新安装；或重置（更多工作 - 文件数据独家恢复）
如果一切都失败了，你可以继续尝试并从现在的位置重新开始，这样你的系统就可以重新启动，而不需要重新安装任何东西或复制任何东西（更多尝试-完全系统恢复）

既然你提到你是“在确定可以访问备份磁盘上的数据之前，犹豫不决“，我假设你只是想在修复 PC 时备份数据，并假设fdiskas输出中提到的扩展分区/dev/sda2不包含任何需要保留的数据，并且这只与/dev/sda5它有关，因为它被提及

...但是没有 /dev/sdb5 我就无法挂载 LUKS 加密卷，也无法访问我的数据。

然后，我建议您更改您的选项和标志，dd这样就不会通过将整个磁盘直接复制到备用磁盘来备份整个磁盘，而是通过更改指向保存在已安装备用磁盘上的映像文件来制作整个磁盘的备份映像副本of，dd然后您可以将该映像虚拟安装为虚拟系统，以避免备用驱动器上的任何分区冲突，或者更好的是，更改标志if并dd仅复制您需要的分区，如果/dev/sda5使用安装两个磁盘并从实时系统启动时引用的命名方案。

由于您在复制磁盘时没有使用oflag=direct或选项，因此我强烈建议您查看oflag=syncdd 手册页如果执行上述操作，则可选择以下选项。

解答你的疑问

我的理解是 dd 会复制每个字节，并且不会遗漏任何隐藏的元数据，但我不是现代磁盘控制器方面的专家。我遗漏了什么吗（除了 /dev/sdb5）？

是的，你说得对，但正如我们所发现的，如果没有正确记录隐藏元数据，可能会忽略一些小的写入错误。因为它读取得很好，只是不能写入。因此，虽然很难量化你遗漏了什么，因为你似乎已经知道了不少，但我至少要简单提一下，它会逐字节dd复制每个位，甚至复制未分区空间的空白或 NULL 字节，甚至复制未标记的“空白空间”，文件曾经存在但被删除，可以恢复，因此如果使用“dd”的副本包含该“空白空间”，则可以恢复。但它所做的远不止简单地读取stdin和输出，stdout尽管它需要合并一些选项，但我离题了。

如果有的话，我敢说大多数人可能经常忘记考虑的事情是复制每个字节的实际含义或翻译，这取决于场景和从中复制/读取的内容或使用保存数据的介质，例如与被复制的源在大小或类型上不相似的设备。详细说明这一点的一个具体参考是，如果它不能被读取，dd它就不能被写入dd。因此，在将文件系统从一个驱动器复制到几乎或完全相似的驱动器方面，某些硬件级别编码的数据将不会被转移，而依赖于硬件寻址的其他数据的信息位未存储在文件或设备本身中，这些信息将不会改变。但对一些人来说，这是显而易见的，而对另一些人来说则不是。可以肯定的是，如果它存在于一个块上并且可以被计算机读取但不向用户显示，那么它就可以被复制。

我需要在笔记本电脑上做些什么吗？如果它是原始密码的真正字节克隆，则密码应该相同。

正如我们现在所推测的，问题不是笔记本电脑造成的，而是数据被复制到不匹配的硬件和不匹配的分区方案上（但后者更重要，后面会解释），导致分区无法被操作系统识别，从而导致无法挂载。至于密码相同，是的，你是对的，密码是一样的。

更进一步来说，正如LUKS 常见问题在下面1.2 警告 - 克隆/成像：

如果您克隆或镜像 LUKS 容器，则会复制 LUKS 标头，并且主密钥将保持不变！这意味着，如果您将映像分发到多台机器，则无论您是否更改密码，所有机器都将使用相同的主密钥。

是的，你是对的，它是一样的。但你的问题不是它无法识别密码，而是分区本身。

更详细的解释（不太技术性）

虽然在检查错误消息后，分区方案不匹配被列为问题的嫌疑人，但该结论源于许多被认为适用的经验，但与它们有关的细节被省略，可能是因为它们与问题的产生似乎无关。这些考虑因素包括：

了解主 Linux 系统 SSD 的分区方案，确定其具有 MBR 分区方案，因为提到这/dev/sda2是一个扩展分区，并且仅存在于 MBR 中。缺少的确凿证据是 PC 是在 BIOS/Legacy 中运行，还是在支持 CSM 的 UEFI 中运行
由于不知道主板的 BIO 或 UEFI 设置，我们不知道实时启动棒是在传统模式还是 UEFI 模式下启动的，但它必须与桌面相匹配，才能在连接时识别两个磁盘。不过，我们无法定义“被识别”，因为要对每个字节进行正确的复制，需要离线复制，这意味着您不会安装它们来查看是否真的可以访问它们。但我们也不知道使用什么系统进行复制，也不知道使用了dd哪个版本的dd
确定备用硬盘的分区方案 - 关于备用硬盘的来源、格式、来源（如果是 Linux PC 或 Windows PC）的信息并不多，这些信息将极大地帮助确定写入的数据的目的地（发现错误的地方）
最后，我们知道笔记本电脑在备份之前可以看到驱动器，因此如果运行 UEFI 或以 BIOS 模式启动，它必须具有 CSM 支持。当它能够访问备份的前 2 个分区但看不到第 3 个 luks 加密分区时，可以推断这与 OS 系统识别无关，而是缺少分区头信息导致无法查看驱动器。

附加说明和注意事项

一些琐碎的注释可以帮助你将来更有效地获得帮助或找到答案，请随意接受或拒绝，因为我只提供它们作为建议，而不是任何形式的批评或嘲笑，因为我相信任何人都可以同样从这篇文章中指出我的错误（意思是说我并不比你好），恕我直言：

如果您还不知道，“分区”和“卷”通常不能互换，从技术上讲，它们是指硬盘的不同存储单元。而卷是具有单个文件系统的单个可访问存储区域。分区是硬盘的逻辑分区。虽然这可能只是本文的语义问题，但在尝试理解所发生的事件时，它可能有助于在其他场景中减少误解
请尽量保持参考的一致性，您显示的fdisk输出指示/dev/sda1 /dev/sda2和，/dev/sda5但随后提到使用cryptsetup我/dev/s**d**b5理解设备位置随每个系统而变化，但它可能会对您具体尝试的内容造成混淆，例如什么、何时和何地。即看到如何fdisk显示/dev/sda上下文的分区我可以假设这是在笔记本电脑上运行的，当您提到命令时dd，通过输入标志（或if=）判断我可以假设它是源磁盘，但如果我根据提供的信息假设它cryptsetup是在与 fdisk 中引用的相同驱动器上运行的，dd那么它必须在不同的系统上才能具有不同的设备分配。相反，如果我假设它是笔记本电脑，那么我必须假设发生了某种交换以构成相同的驱动器或者它不是接收设备映射名称更改的相同设备。虽然在这种情况下它可能不那么相关，但在其他情况下它可能意味着一个错误而不是另一个错误。
考虑到上述两点，当您提到源磁盘是 1.8 TB SSD 而目标磁盘是 3TB HDD，但随后显示gdisk5TB 磁盘的输出时，您可能会更加清楚这有多么令人困惑，这表明要么是引用 3 TB 磁盘时出现了拼写错误，要么您的意思是说 HDD 的 3TB 分区，而后者有助于指出由执行命令选项标志而不是其他原因导致的问题。
虽然您提到“我怀疑这很重要”，但在备份时，驱动器的大小和类型非常重要dd。尤其是如果它是重要的数据，不能被视为细微差别，那么最好注意这些事情，因为我会提出可能导致使用后未报告的错误的问题dd（例如仅dmesg在缓冲区膨胀) 如果不是这里所述情况，更具体地说，当您从低容量驱动器传输到高容量驱动器以及从固态驱动器传输到硬盘驱动器时，可以使用有效的选项来dd缓解性能问题、缓存错误以及最终传输数据的可靠性。（虽然我删除了原始的总结，说明所有这些都很重要，因为它无论如何都无法帮助您解决问题）

使用 dd 克隆 LUKS 加密磁盘时出现意外行为

答案1

答案2

更新的问题：

过时且不适用的过于简单化的解释

下一步——备份您的数据

解答你的疑问

更详细的解释（不太技术性）

附加说明和注意事项

相关内容