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

我曾经dd克隆过这样的磁盘：

 dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync

而且它始终运行良好。任何有关“ dd”的文档都会竭力提醒您，目标磁盘的大小必须等于或大于源磁盘的大小。这绝对是必须的吗？

现在，我很明白，如果我克隆到一个较小的磁盘，我不能指望 目标上甚至部分 “超出范围”的任何分区都完好无损。

但是，非常清楚我以后需要在目标上编辑分区，删除“越界”分区，我是否仍可以使用“ dd”对源进行强力复制，直至达到限制目标的物理尺寸？否则，当目标达到其大小极限时，“ dd”会将目标减少为一堆残骸；-)

顺便说一句，通过研究，我看到bs=了从bs=1024到的所有内容的推荐值bs=32M，什么才是最好的？

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

如果要进行此复制，则首先必须使用一些知道其内部结构并能够将所有顺序良好地映射到较小分区的工具来缩小分区。然后，您可以进行复制。gparted是执行此类操作的良好GUI界面。

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

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

尽管起初提议的“挑战”似乎有些困难，不可行或听起来有些幼稚，但事实并非如此。使用dd从较大的磁盘迁移到较小的磁盘的主要思想非常好，并且具有迁移数据的好处。当然，必须有足够的可用空间以使所占用的数据适合目标磁盘。

这样做的想法是单独考虑每个分区，而不是像最初建议的那样立即考虑整个磁盘。甚至可以完成更多工作：在文件系统调整工具的帮助下，可以将被截断的分区安全地迁移。确实，这种迁移很有趣，可以保留文件系统matadata和扩展文件属性，而这些文件属性无法通过cp，rsync，pax等工具轻松复制，这些工具在文件系统层而不是在设备层运行。使用dd不需要重新安装OS或重新标记FS，以避免SELinux出现问题。

以下是我通常要完成的任务：

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

2）考虑到其空间限制，使用适当的几何形状对目标磁盘进行分区；

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

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

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

祝好运！...并且最重要的是，请记住在进行此类操作之前备份所有重要数据。一个错误，您肯定会无法挽回地损坏您的数据。

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

如果您想将汽车安装在比汽车窄20厘米的通道中，并且又将汽车的左侧切成20厘米，那汽车还能工作吗？可能不会。

如果将一个磁盘的开头复制到另一个磁盘上，并由于目标磁盘较小而将其剪切短，那么结果将无法正常工作。即使有足够的空间来容纳目标磁盘上的所有文件，从磁盘起始处切入N个字节也无法使文件系统正常工作。

如果将磁盘划分为PC样式的分区（GPT或MBR），则完全适合目标的所有分区都可以使用。有一个例外：对于MBR分区，如果未按磁盘顺序编号逻辑分区，则一旦链离开目标区域，分区将不再列出。（如果您不了解这一点，那是不进行部分磁盘复制的另一个原因。）复制要保留的分区，而不是从头开始复制并以任何合适的方式结束，这将更加有意义。 。最后部分复制的分区将不可用。

如果磁盘或部分分区是LVM物理卷，并且您对该物理卷进行了部分复制，则也不能确保从结果中获取任何有用的数据。

如果仅要将某些数据从大磁盘复制到小磁盘，请在小磁盘上创建分区。如果要将分区复制到相同大小的分区，可以使用进行操作cat。如果要将分区复制到较小的分区，请在目标分区上创建文件系统，并使用cp -a或进行文件级复制pax -rw -pe -t。

如果您是受虐狂，可以使用dd代替cat。dd语法很奇怪，通常比cat除非找到正确的缓冲区大小要慢。缓冲区大小没有一个最佳值，它取决于硬件的特性。如果尺寸太小，dd将浪费时间进行许多微小的转移。如果大小太大，dd将浪费时间完全读取一个缓冲区，然后再开始写入下一个缓冲区。磁盘到磁盘传输的最佳大小通常为几兆字节（1024字节太小了）。cat会毫不费力地选择合适的尺寸。

如果这对其他读者有用，我想分享我在该主题上的经验。最近，我使用DDRESCUE从出现故障的硬盘驱动器中恢复了NTFS分区的前1/3，并成功地将分区的恢复段重建到了较小的硬盘驱动器上-从而拯救了捕获的文件（并丢失了其余文件）。以下是我这样做的步骤（绝对是一种HACKSAW方法！） ...

源硬盘驱动器由750GB的NTFS格式的格式化以及MBR文件表组成。我仅用过几次备份文件，因此大多数文件位于驱动器的开头，价值约160GB。一位家庭成员将硬盘驱动器（外部安装）敲到了地板上–此后再也无法正常工作！使用ddrescue（辛苦地），我能够恢复驱动器大部分的开始。由于物理损坏，它在整个过程中非常频繁地关闭...

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

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

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

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

这是磁盘探针在编辑NTFS引导扇区数据的操作中的图像

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

下一部分我不明白其原因，因为Windows确实成功地重建了包含文件的150GB硬盘。但是，Windows本身无法打开硬盘驱动器分区以进行文件查看（存在一些错误）。但是Ubuntu可以解救！我重新启动进入Ubuntu，安装了外部硬盘驱动器，并且毫无问题，所有恢复的文件都显示了！

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

您需要首先缩小源上的分区（或删除那些越界）。
比dd后你可能会需要使用修复分区表gdisk /dev/sd<target>
和键序列修表的v r d w
，我建议你到shring分区比需要小一点，后扩大他们回到目标磁盘的全部尺寸。
（此答案基于我将我的硬盘克隆到较小的SSD时的个人经验）