知道分区需要编辑后，可以使用“dd”克隆到较小的硬盘吗？

Question 1

正如其他人在这里提到的那样，dd由于 GPT 表的副本放置在磁盘末尾，因此使用 just 不起作用。

我已成功使用以下方法迁移到较小的驱动器：

首先 - 启动到您选择的 liveCD 发行版。

调整源驱动器分区的大小以确实适合较小驱动器的限制（gparted例如使用）。然后，假设sda是源磁盘，使用sgdisk，首先从源驱动器创建 GPT 表的备份以确保安全：`

    sgdisk -b=gpt.bak.bin /dev/sda

假设sdb是目标，将表从源驱动器复制到目标：

    sgdisk -R=/dev/sdb /dev/sda

sgdisk现在会抱怨它尝试将标头副本放置在目标磁盘的边界之外，但随后会回退并将标头正确放置在目标磁盘的上限。

gparted验证是否已使用您选择的工具（例如）在目标驱动器上创建了正确的分区表克隆。

使用dd，将每个分区从源驱动器复制到目标：

dd if=/dev/sda1 of=/dev/sdb1 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda3 of=/dev/sdb3 bs=1M conv=sync,noerror,notrunc status=progress
etc...

dd显然，如果您在没有备份的情况下复制 GPT 分区表或在读取内容时混淆了驱动器名称，您就可以与内容说再见了:)

Answer

正如其他人在这里提到的那样，dd由于 GPT 表的副本放置在磁盘末尾，因此使用 just 不起作用。

我已成功使用以下方法迁移到较小的驱动器：

首先 - 启动到您选择的 liveCD 发行版。

调整源驱动器分区的大小以确实适合较小驱动器的限制（gparted例如使用）。然后，假设sda是源磁盘，使用sgdisk，首先从源驱动器创建 GPT 表的备份以确保安全：`

    sgdisk -b=gpt.bak.bin /dev/sda

假设sdb是目标，将表从源驱动器复制到目标：

    sgdisk -R=/dev/sdb /dev/sda

sgdisk现在会抱怨它尝试将标头副本放置在目标磁盘的边界之外，但随后会回退并将标头正确放置在目标磁盘的上限。

gparted验证是否已使用您选择的工具（例如）在目标驱动器上创建了正确的分区表克隆。

使用dd，将每个分区从源驱动器复制到目标：

dd if=/dev/sda1 of=/dev/sdb1 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda3 of=/dev/sdb3 bs=1M conv=sync,noerror,notrunc status=progress
etc...

dd显然，如果您在没有备份的情况下复制 GPT 分区表或在读取内容时混淆了驱动器名称，您就可以与内容说再见了:)

Question 2

至少物理驱动器不应该开始冒烟，但是您的文件系统很可能将不再工作（我的意思是目标文件系统；如果您只是复制并且没有触及源中的任何内容，则源本身应该没问题）。分区内的数据不一定按升序分配。即使分区未满，其中一些也可能位于分区的末尾（实际上，我认为这种情况在某些文件系统中确定性地发生，但我不知道足够的细节来了解）。那里的数据对于文件系统的完整性可能至关重要。所以我强烈建议你不要依赖这样的副本。

如果要执行此复制，首先必须使用某种工具缩小分区，该工具了解其内部结构，并且能够将所有内容按良好顺序重新映射到较小的分区中。然后就可以进行复印了。gparted是一个很好的 GUI 界面来完成这类事情。

对于bs价值，通常最好的想法是在开始真正的副本之前进行几次测试。有一些工具可以帮助您自动执行此检查，但我不记得名称了。根据我的经验，最佳范围通常在 4M 到 16M 之间。高于这个数字你就赚不了多少钱了。但这取决于很多因素，包括磁盘本身。例如，我很少使用真正的高端磁盘，由于速度和缓存大小较大，这些磁盘可能适合更高的值。

编辑如果一个分区被完全复制，那么您可以毫无问题地使用它。但是，正如其他人所强调的那样，您还必须确保分区表完好无损（至少是相关条目）。 MBR 的四个主分区没有问题，因为它们是在磁盘的前 512 字节中描述的。逻辑分区是在整个扩展分区中描述的，因此条目可能会丢失（但它们会描述无论如何都会丢失的分区）。对于 GPT，磁盘的开头和结尾都有分区表的副本。你失去了第二个，但你可以从第一个重建它。当然，建议尽快这样做；对此，其他答案更为准确。

Answer

至少物理驱动器不应该开始冒烟，但是您的文件系统很可能将不再工作（我的意思是目标文件系统；如果您只是复制并且没有触及源中的任何内容，则源本身应该没问题）。分区内的数据不一定按升序分配。即使分区未满，其中一些也可能位于分区的末尾（实际上，我认为这种情况在某些文件系统中确定性地发生，但我不知道足够的细节来了解）。那里的数据对于文件系统的完整性可能至关重要。所以我强烈建议你不要依赖这样的副本。

如果要执行此复制，首先必须使用某种工具缩小分区，该工具了解其内部结构，并且能够将所有内容按良好顺序重新映射到较小的分区中。然后就可以进行复印了。gparted是一个很好的 GUI 界面来完成这类事情。

对于bs价值，通常最好的想法是在开始真正的副本之前进行几次测试。有一些工具可以帮助您自动执行此检查，但我不记得名称了。根据我的经验，最佳范围通常在 4M 到 16M 之间。高于这个数字你就赚不了多少钱了。但这取决于很多因素，包括磁盘本身。例如，我很少使用真正的高端磁盘，由于速度和缓存大小较大，这些磁盘可能适合更高的值。

编辑如果一个分区被完全复制，那么您可以毫无问题地使用它。但是，正如其他人所强调的那样，您还必须确保分区表完好无损（至少是相关条目）。 MBR 的四个主分区没有问题，因为它们是在磁盘的前 512 字节中描述的。逻辑分区是在整个扩展分区中描述的，因此条目可能会丢失（但它们会描述无论如何都会丢失的分区）。对于 GPT，磁盘的开头和结尾都有分区表的副本。你失去了第二个，但你可以从第一个重建它。当然，建议尽快这样做；对此，其他答案更为准确。

Question 3

尽管最初提出的“挑战”可能看起来很困难、不可行，或者像一些人评论的那样听起来很天真，但事实并非如此。使用 dd 从较大磁盘迁移到较小磁盘的主要思想非常好，并且对迁移数据有好处。当然，有足够的可用空间以便所占用的数据适合目标磁盘是必要的要求。

这个想法是考虑单独添加每个分区，而不是像最初建议的那样一次性添加整个磁盘。还可以完成更多工作：借助文件系统调整大小工具的一点帮助，也可以安全地迁移将被截断的分区。事实上，为了保留文件系统元数据和扩展文件属性，这种迁移很有趣，而这些属性无法使用 cp、rsync、pax 等工具轻松复制，这些工具在文件系统层而不是块设备层运行。使用 dd 无需重新安装操作系统或重新标记 FS 以避免 SELinux 问题。

以下是我通常为完成类似任务所做的事情：

1) 首先，您需要减少受影响分区中将被截断的文件系统。为此，请使用 resize2fs 工具（假设我们正在讨论 ext2/ext3/ext4 fs - 其他现代 FS 也具有用于相同目的的调整大小工具）。请注意，尽管出于显而易见的原因，文件系统不能大于它所在的分区，但它可以安全地小一些。这里的安全技巧是减少“超过需要的”。例如：假设您有一个 1TB 的文件系统，想要迁移到 500 Gig 驱动器。在这种情况下，我建议将文件系统减少到450 Gig（当然，您必须有足够的可用空间，即该文件系统中当前占用的空间不能超过450 Gig）。明显浪费的 50 Gig 空间将在数据迁移后修复。

2) 考虑到目标磁盘的空间限制，使用适当的几何结构对目标磁盘进行分区；

3) 使用分区设备而不是磁盘设备添加数据（即，使用dd if=/dev/sda# of=/dev/sdb#每个分区而不是使用if=/dev/sda of=/dev/sdb）。注意：这里的sda和sdb只是示例；重要提示：当从较大的分区设备写入较小的分区设备时，dd 会抱怨尝试将 post 写入块设备的末尾，这是可以的，因为文件系统数据在到达该点之前已被完全复制。为了避免此类错误消息，您可以使用bs=参数指定副本的大小count=以匹配缩小的文件系统大小，但这将需要一些（简单的）计算，但如果操作错误可能会危及您的数据。

4) 添加数据后，再次使用 resize2fs 调整目标分区内相应文件系统的大小。这次不指定新的文件系统大小。当在没有大小指定的情况下运行时，resize2fs 会增长文件系统，使其占据允许的最大大小，因此，在这种情况下，450 Gig 文件系统将再次增长以占据整个 500 Gig 分区，并且不会浪费任何字节。（“减少超过需要的数量”方法可避免您意外错误地指定大小并导致数据面临风险。请注意，GB 与 GiB 单位可能会很棘手）。

对于更复杂的操作，请注意：如果您打算复制一个启动管理器（很可能是这种情况），您可以使用磁盘设备而不是分区设备来添加磁盘的前几个 KB（如dd if=/dev/sda of=/dev/sdb bs=4096 count=5），然后重新配置 /dev/sdb 中的几何结构（其中将暂时包含新驱动器的无效几何结构，但包含完整且有效的引导管理器）。最后继续使用如上所述的分区设备一次添加一个分区。这样的操作我做过很多次了。最近，我在 MacMini6,2 中从包含 MacOSX 和 Linux 安装混合的 HDD 升级到较小的 SDD 时，成功执行了复杂的迁移。在这种情况下，我必须从外部驱动器启动 Linux，dd'ed 启动管理器，运行 gdisk 来修复新磁盘中的 GPT，最后 dd'ed 包含刚刚缩小的文件系统的每个分区。（请注意，GPT 分区方案保留分区表的两份副本，一份在磁盘的开头，另一份在磁盘的末尾。gdisk 抱怨很多，因为它找不到 PT 的第二个副本，并且分区超出了磁盘大小，但它在重新定义磁盘几何形状后正确修复了 PT 复制问题）。这是一个复杂得多的案例，但值得一提，因为这表明这种操作也是完全可行的。

祝你好运！ ...最重要的是记住在进行此类操作之前备份所有重要数据。一个错误肯定会导致您的数据受到不可挽回的损坏。

以防万一我强调得不够：在迁移之前备份您的数据！ :)

Answer

尽管最初提出的“挑战”可能看起来很困难、不可行，或者像一些人评论的那样听起来很天真，但事实并非如此。使用 dd 从较大磁盘迁移到较小磁盘的主要思想非常好，并且对迁移数据有好处。当然，有足够的可用空间以便所占用的数据适合目标磁盘是必要的要求。

这个想法是考虑单独添加每个分区，而不是像最初建议的那样一次性添加整个磁盘。还可以完成更多工作：借助文件系统调整大小工具的一点帮助，也可以安全地迁移将被截断的分区。事实上，为了保留文件系统元数据和扩展文件属性，这种迁移很有趣，而这些属性无法使用 cp、rsync、pax 等工具轻松复制，这些工具在文件系统层而不是块设备层运行。使用 dd 无需重新安装操作系统或重新标记 FS 以避免 SELinux 问题。

以下是我通常为完成类似任务所做的事情：

1) 首先，您需要减少受影响分区中将被截断的文件系统。为此，请使用 resize2fs 工具（假设我们正在讨论 ext2/ext3/ext4 fs - 其他现代 FS 也具有用于相同目的的调整大小工具）。请注意，尽管出于显而易见的原因，文件系统不能大于它所在的分区，但它可以安全地小一些。这里的安全技巧是减少“超过需要的”。例如：假设您有一个 1TB 的文件系统，想要迁移到 500 Gig 驱动器。在这种情况下，我建议将文件系统减少到450 Gig（当然，您必须有足够的可用空间，即该文件系统中当前占用的空间不能超过450 Gig）。明显浪费的 50 Gig 空间将在数据迁移后修复。

2) 考虑到目标磁盘的空间限制，使用适当的几何结构对目标磁盘进行分区；

3) 使用分区设备而不是磁盘设备添加数据（即，使用dd if=/dev/sda# of=/dev/sdb#每个分区而不是使用if=/dev/sda of=/dev/sdb）。注意：这里的sda和sdb只是示例；重要提示：当从较大的分区设备写入较小的分区设备时，dd 会抱怨尝试将 post 写入块设备的末尾，这是可以的，因为文件系统数据在到达该点之前已被完全复制。为了避免此类错误消息，您可以使用bs=参数指定副本的大小count=以匹配缩小的文件系统大小，但这将需要一些（简单的）计算，但如果操作错误可能会危及您的数据。

4) 添加数据后，再次使用 resize2fs 调整目标分区内相应文件系统的大小。这次不指定新的文件系统大小。当在没有大小指定的情况下运行时，resize2fs 会增长文件系统，使其占据允许的最大大小，因此，在这种情况下，450 Gig 文件系统将再次增长以占据整个 500 Gig 分区，并且不会浪费任何字节。（“减少超过需要的数量”方法可避免您意外错误地指定大小并导致数据面临风险。请注意，GB 与 GiB 单位可能会很棘手）。

对于更复杂的操作，请注意：如果您打算复制一个启动管理器（很可能是这种情况），您可以使用磁盘设备而不是分区设备来添加磁盘的前几个 KB（如dd if=/dev/sda of=/dev/sdb bs=4096 count=5），然后重新配置 /dev/sdb 中的几何结构（其中将暂时包含新驱动器的无效几何结构，但包含完整且有效的引导管理器）。最后继续使用如上所述的分区设备一次添加一个分区。这样的操作我做过很多次了。最近，我在 MacMini6,2 中从包含 MacOSX 和 Linux 安装混合的 HDD 升级到较小的 SDD 时，成功执行了复杂的迁移。在这种情况下，我必须从外部驱动器启动 Linux，dd'ed 启动管理器，运行 gdisk 来修复新磁盘中的 GPT，最后 dd'ed 包含刚刚缩小的文件系统的每个分区。（请注意，GPT 分区方案保留分区表的两份副本，一份在磁盘的开头，另一份在磁盘的末尾。gdisk 抱怨很多，因为它找不到 PT 的第二个副本，并且分区超出了磁盘大小，但它在重新定义磁盘几何形状后正确修复了 PT 复制问题）。这是一个复杂得多的案例，但值得一提，因为这表明这种操作也是完全可行的。

祝你好运！ ...最重要的是记住在进行此类操作之前备份所有重要数据。一个错误肯定会导致您的数据受到不可挽回的损坏。

以防万一我强调得不够：在迁移之前备份您的数据！ :)

Question 4

我想分享我在这个主题上的经验，如果这对其他读者有用的话。最近我用过DDR救援从故障硬盘中恢复 NTFS 分区的前 1/3，并成功地将恢复的分区段重建到较小的硬盘上 - 从而挽救捕获的文件（并丢失其余部分）。以下是我这样做的步骤（绝对是钢锯方法！！）...

源硬盘由 750GB 的 NTFS 格式和 MBR 文件表组成。我只用过它几次来备份文件，所以大部分文件都在驱动器的开头，大约有160GB。一名家庭成员将硬盘驱动器（安装在外部）撞到地板上 - 此后它就再也不能正常工作了！使用 ddrescue （煞费苦心地），我能够恢复驱动器开头的大部分内容。由于物理损坏，整个过程中非常频繁地关闭......

我有一个可用的 150GB 小型笔记本电脑硬盘（外部安装），我将 ddrescue 数据直接提取到其中。或者，我可以将数据提取到图像文件，然后安装该文件，但我认为将数据直接写入硬盘更简单。

救援的关键技巧是手动编辑救援硬盘上的 MBR 和 NTFS 引导扇区数据。如果不这样做，任何操作系统都无法识别硬盘驱动器。我在linux下找不到合适的程序来做到这一点，所以我转向了windows。有一个名为 Windows 支持工具的方便包，不再维护，但仍然有用（请参阅下面的链接）！我用来编辑分区的工具是Disk Probe。确保知道你的硬盘的结束扇区值（我在Ubuntu中使用了fdisk -l）

https://en.wikipedia.org/wiki/Windows_Support_Tools

使用一个好的计算器和一些创造力，我将硬盘驱动器加载并安装到 Windows 中的 Disk Probe 中，并编辑了最终扇区值。在 MBR 中，必须更改两组值，即 a) 硬盘驱动器结束扇区和 b) NTFS 分区结束扇区。在 NTFS 引导扇区中，必须更改分区总扇区值。在每种情况下，数值都会减小，以匹配较小硬盘驱动器减小的“尺寸”（末端扇区从 750GB 更改为 150GB）。单击“视图”选项卡可编辑这些值。

这是 Disk Probe 正在编辑 NTFS 引导扇区数据的图像

编辑上述字段后，Windows 将该分区识别为有效分区，尽管已损坏。我进入命令提示符并在损坏的硬盘上运行 Windows 程序 Chkdsk (chdsk D:)。看到分区逐个文件地恢复活力真是令人兴奋！该程序重建了分区表，并成功重新映射了从损坏的硬盘驱动器复制过来的所有文件。未找到超出范围（未复制）的文件，因此被删除。

接下来的部分我不明白原因，因为 Windows 确实成功重建了 150GB 硬盘并包含文件。尽管如此，Windows 本身无法打开硬盘分区进行文件查看（存在一些错误）。不过 Ubuntu 可以拯救你！我重新启动到 Ubuntu，安装了外部硬盘驱动器，完全没有问题，所有恢复的文件都显示出来了！

希望这种将文件从大硬盘驱动器恢复到较小硬盘驱动器的钢锯方法将对除了我之外的其他可怜的人有用。干杯!

Answer