dd克隆前必须先收缩分区，否则会全盘复制浪费时间；需匹配目标盘容量与分区表类型；必须加bs=4m、status=progress、conv=fsync,noerror参数；克隆后须验证启动与fstab配置。
dd 克隆前必须收缩分区，否则白等几小时
直接 dd if=/dev/sda of=/dev/sdb 看似简单，但若源盘是 1TB 只用了 20GB 的 SSD，dd 仍会逐块复制全部 1TB —— 包括那 980GB 的“空白”空间。这不是浪费时间，是实打实的 I/O 延迟，尤其在机械盘上可能耗时数小时。
真正该做的，是先缩小文件系统，再克隆有效数据区域：
- 用 Live 系统（如 Ubuntu Desktop ISO）启动，运行
gparted，右键源分区 → “Resize/Move”，拖到最小合理尺寸（保留 1–2GB 余量） - 对 ext4 分区也可命令行操作：
e2fsck -f /dev/sda1校验后，resize2fs /dev/sda1 M（M 是估算的最小大小，单位 MB） - NTFS 分区建议在 Windows 下用
diskmgmt.msc缩小，Linux 下 ntfs-3g resize 支持有限且风险高
缩完再 dd，实际写入量可能从 TB 级降到 GB 级，速度提升 10 倍以上。
目标盘容量和分区表类型必须匹配
dd 是裸设备级复制，不关心文件系统逻辑，只按字节搬运。这意味着：源盘是 MBR，目标盘也得是 MBR；源盘是 GPT + ESP 分区，目标盘必须有足够空间容纳整个 GPT 头 + 所有分区起始偏移，否则启动失败或数据错位。
常见翻车点：
- 目标 SSD 实际容量略小于标称值（如标 500GB，实际 465GiB），而源盘分区表末尾扇区刚好卡在临界点 →
dd写入时截断，分区丢失 - 新盘未初始化或分区表类型不同（比如源是 GPT，目标是空盘默认无分区表）→ 虽然
dd成功，但 BIOS/UEFI 可能无法识别启动项 - 误将
/dev/sdb1当作目标设备（写入单一分区），而非/dev/sdb（整盘），导致仅覆盖第一个分区，其余分区结构全毁
安全做法：用 fdisk -l /dev/sda 和 fdisk -l /dev/sdb 对比总扇区数与分区布局；确认目标盘已用 gdisk 或 fdisk 初始化为同类型分区表。
加参数不是可选，是保命刚需
裸跑 dd if=/dev/sda of=/dev/sdb 就像蒙眼开车——没进度、遇坏块就停、掉电可能丢一半数据。以下三个参数几乎必加：
-
bs=4M：块大小设为 4MB（非 512B 或 64K），现代 SSD/HDD 顺序读写最适配，效率提升明显；太大会吃光内存缓存，太小则系统调用开销剧增 -
status=progress：内建进度条，实时显示已复制字节数和速率，不用另开终端发kill -USR1 -
conv=fsync,noerror：fsync强制落盘，避免缓存未刷导致“显示完成但实际没写完”；noerror遇坏扇区跳过（对老硬盘很关键），否则整个克隆中断
完整推荐命令：sudo dd if=/dev/sda of=/dev/sdb bs=4M status=progress conv=fsync,noerror
克隆完不能直接拔线，验证步骤不能省
克隆成功 ≠ 系统可用。尤其涉及启动盘时，最容易忽略验证环节：
- 用
blkid检查目标盘分区 UUID 是否与源盘一致（正常，因为dd复制了所有元数据）；若需唯一性，后续用tune2fs -U random /dev/sdb1重生成 - 挂载目标盘分区：
sudo mount /dev/sdb1 /mnt，检查/mnt/etc/fstab中的 UUID 或设备名是否仍指向原盘路径（如写死/dev/sda1就要改） - 最关键一步：重启，从新盘启动。不要只看 BIOS 能识别，要进系统桌面或命令行，运行
df -h确认根分区确实是/dev/sdb1
很多“克隆失败”的案例，其实是克隆完成了，但 fstab 没改、initramfs 没更新、或 UEFI 启动项没重建——这些都不是 dd 的责任，但却是迁移成败的分水岭。
