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

[编辑] 在花费大量时间起草、修改、查找参考资料、引用和发布此答案之后，我至少可以说 OP 已经回答了他们自己的问题。我最初的想法是删除我的答案，因为其中大部分是无关紧要的，但在投入大量时间可能毫无意义的事情之后，这仍然很困难。尽管我希望解决 OP 的未标记答案中提到的新发现的问题。

更新问题：

使用具有正确偏移量的环回设备确实允许安装和访问分区 --- 尽管我似乎仍然无法访问 LUKS sdb5 分区（因为它没有被报告），即使我输入了从计算的地址原始驱动器上的偏移量。数据就在那里，但令人费解的报告使 cryptsetup 无法正常工作。不确定除了获得不那么自以为是的 USB 机箱之外是否还有其他解决方法。

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

...碰巧我的回答确实适用。然后也许使用循环设备场景，您可以计算原始驱动器的偏移量，您可以尝试使用此脚本来确定当它作为 USB 连接时报告的偏移量，以解决无法识别的分区。

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

[结束编辑]

旧的和不适用的过度简化的解释

发生的情况是，您可能没有格式化在dd用于备份主要 linux 安装之前找到的备用磁盘，并且您在主要 linux 安装硬盘驱动器上的内容是MBR 分区方案，而备用磁盘具有GPT 分区方案。

@oldfred已经在评论中指出了这一点，但尚未收到对输出以下命令的请求的响应

sudo gdisk -l /dev/sdb

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

因此，当您过去dd将整个磁盘复制到备用磁盘上时，该磁盘比原始（或源）磁盘大，并且实际上是逐字节复制驱动器的字节，因此它通过分区方案复制（包括前硬盘的分区表和标题）并将其放置在较大磁盘的 GPT 分区方案之上。这意味着它会被 GPT 的保护 MBR 层阻止，该层旨在防止基于 MBR 的磁盘实用程序错误识别并可能覆盖 GPT 磁盘，并与位于设备开头的 LUKS 标头冲突，在同一个地方保护 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“无怨无悔”完成时，live bootstick系统能看到第三个分区吗？？因为如果可以的话，是否有任何尝试从那里访问您的数据？如果两者都是，那么这可能会使我刚才认为的一切无效，您的硬盘驱动器机箱的控制器可能是嫌疑人。

嗯嗯...

前进 - 备份您的数据

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

1. 备份您的数据，以便在尝试修复主 PC 时不会丢失数据，您可以在修复后将该数据复制回 PC；或者
2. 如果要创建与您的主 PC 完全相同的副本，以便如果您搞砸了修复“损坏的安装”的任何尝试，您可以从头开始

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

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

既然您提到“在 [您] 确定 [您] 可以访问 [您的] 备份磁盘上的 [您的] 数据之前，您会犹豫做任何事情”，我假设您只想备份您的数据当您着手修复您的 PC 并假设fdiskas的输出中提到的扩展分区/dev/sda2不包含任何需要保留的数据时，这只是/dev/sda5相关的，因为它被提到了

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

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

由于您在复制磁盘时避免使用oflag=director选项，因此我强烈建议您在执行上述操作时查看dd 手册页中的选项。oflag=sync

解决您的问题

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

是的，您是对的，但正如我们所发现的，如果没有正确记录隐藏的元数据，可能会忽略轻微的写入错误。因为它读得很好，它就是写不出来。所以，虽然很难量化你所缺少的东西，因为你似乎已经知道很多了，但我至少会简单地提到dd，确实会逐字节复制每一位，而且它会走这么远甚至复制未分区空间的空白空间或 NULL 字节，甚至复制曾经存在但被删除但可以恢复的未标记的“空白空间”，因此如果使用“dd”的副本包含该“空白空间”，则可以恢复。但它不仅仅是简单地读取stdin和输出，stdout尽管它需要结合一些选项，

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

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

正如我们现在所推测的那样，导致问题的不是笔记本电脑，而是数据精确复制到不匹配的硬件和不匹配的分区方案（但更多的是后者，稍后将解释），导致分区可以' t 被操作系统识别，因此导致无法挂载。至于密码是一样的，是的，你是对的，它是一样的。

更进一步，如1.2 警告 - 克隆/成像下的LUKS 常见问题解答中所述：

如果您克隆或镜像 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 加密分区时，这完全与操作系统系统识别无关，而是缺少分区头信息导致无法查看驱动器。

附加说明和注意事项

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

• 如果还不知道，“分区”和“卷”通常不能互换，并且在技术上指的是硬盘驱动器的不同存储单元。而卷是具有单个文件系统的单个可访问存储区域。分区是硬盘的逻辑分区。虽然这可能只是这篇文章的语义，但在尝试理解发生的事件时，它可能有助于减少在其他场景中的误解
• 请尽量与您的引用保持一致，您显示一个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仅从bufferbloat）如果不是这里规定的情况，更具体地说是当您从较低容量驱动器转移到较高容量驱动器以及从固态驱动器转移到硬盘驱动器时使用的有效选项dd以减轻性能问题、缓存错误以及最终传输数据的可靠性。（尽管我已经删除了所有重要事项的原始摘要，因为无论如何它都无助于解决您的问题）

这似乎与使用 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 分区。

所以......一个关于假设即使是最简单的设备也不会试图“纠正”你的警示故事。在所有可能的世界中，一切都是最好的。