企业官网建设流程全解析

前几天帮朋友把一台老笔记本上的 Ubuntu 系统搬到一块容量更小的 SSD 上，他第一反应是用再生龙做整盘备份再还原，结果恢复时直接卡在“目标硬盘小于源硬盘”的检查上。这个场景太典型了：源盘 1TB，新盘 512GB，实际数据只用了 180GB，理论上完全装得下，但再生龙默认会按源盘分区表去创建分区，目标盘一检查就报错。很多刚接触再生龙备份 Linux 系统的朋友会以为这是工具 bug，其实它只是把“整盘克隆”和“文件级迁移”的边界划得很清楚。这篇文章就从底层逻辑、容量核算、源端瘦身、专家模式参数、文件级迁移、临时大盘中转、引导修复、常见报错排查几个角度，把“再生龙移植 Ubuntu 硬盘大小限制解决方案”一次讲透。无论你是在物理机之间搬系统，还是在 VMware 虚拟机安装 Ubuntu 后想迁到小容量磁盘，或者准备给旧机器做 Ubuntu 系统重装，下面这些步骤都能直接参考。

1. 先搞懂再生龙移植 Ubuntu 时硬盘大小限制到底卡在哪

1.1 再生龙不是简单的 dd 复制，分区表才是第一道门槛

很多人把再生龙理解成“带界面的 dd”，这个认知在整盘同容量克隆时问题不大，但一旦目标盘变小，就会踩坑。dd 是逐扇区复制，源盘 1TB，目标盘 512GB，写到一半必然失败。再生龙比 dd 聪明一些，它默认走的是“保存分区表 + 保存各分区文件系统数据”的路线，恢复时先按源盘的分区表在目标盘上创建分区，再把分区数据写回去。问题在于，源盘分区表里记录的分区结束位置可能已经超过目标盘容量，比如源盘第一个分区从 1MiB 到 500GiB，第二个分区 500GiB 到 900GiB，目标盘只有 476GiB，创建分区表时就会提示目标盘太小。再生龙提供的“-icds”选项可以跳过“目标硬盘是否小于源硬盘”的检查，但跳过检查不等于分区表就合理，后续创建分区、写入数据时仍可能失败。所以真正要解决的不是一个勾选项，而是让目标盘上的分区布局和文件系统大小都落在 476GiB 这个物理边界内。

1.2 目标盘小于源盘时常见的三种翻车场景

第一种是整盘恢复模式直接报错，提示“Target disk is smaller than source disk”，这时候如果只勾选 -icds，继续恢复，可能会发现分区表创建失败，或者恢复到最后几个分区时提示空间不足。第二种是恢复完成了，但系统启动进入 emergency mode，原因通常是 /etc/fstab 里还写着旧分区的 UUID，或者根分区 UUID 变了，系统找不到根文件系统。第三种是能启动但根分区没有占满目标盘，比如源盘根分区 800GB，目标盘根分区只创建了 500GB，但文件系统仍然按 800GB 的元数据挂载，出现“文件系统大小大于分区大小”的异常。这三种场景的根源都一样：源盘的分区尺寸、文件系统尺寸、目标盘物理容量三者没有重新对齐。解决办法要么在源端先缩小分区和文件系统，要么在目标端手动创建更小的分区，再用再生龙的分区恢复模式写数据，绕开整盘分区表的限制。

1.3 为什么 Ubuntu 系统尤其容易遇到这个问题

Ubuntu 默认安装时如果选择“使用整个磁盘”，通常会创建 EFI 分区、/boot 分区、根分区，有时还有 swap 分区，如果启用了 LVM，还会多出物理卷、卷组、逻辑卷几层结构。源盘 1TB 时，根分区可能被自动扩到 900GB 以上，实际已用空间可能只有 200GB。再生龙保存的是文件系统数据，不是真实数据量，恢复时它需要按分区大小准备空间。目标盘 512GB，如果直接按源分区表创建 900GB 根分区，必然失败。另外 Ubuntu 的 GRUB 引导、initramfs、fstab 都依赖分区 UUID，迁移后 UUID 变化，如果只做块级复制而不进 chroot 修复，系统很难顺利启动。再加上 UEFI 和 BIOS 两种引导模式对分区表的要求不同，UEFI 通常需要 GPT 和 EFI 系统分区，BIOS 可以用 MBR 或 GPT，迁移前如果没确认目标盘分区表类型，恢复时也会出各种幺蛾子。

2. 动手前先把账算清楚：容量、分区表和文件系统边界

2.1 已用空间不等于镜像大小，也不等于目标盘可用空间

再生龙备份出来的镜像通常经过压缩，180GB 的已用数据压缩后可能只有 80GB，但这不代表目标盘只需要 80GB。恢复时再生龙要把文件系统恢复到分区里，分区本身要能容纳文件系统的全部元数据和数据。目标盘 512GB 标称容量，实际可用大约 476GiB，文件系统还要留出 5% 到 10% 的保留块给 root，ext4 默认给 root 保留 5%，如果你用 -m 0 可以取消，但不建议在生产系统上取消。再加上分区对齐、EFI 分区、/boot 分区、swap 分区的开销，真正能分配给根分区的可能只有 440GiB 到 450GiB。如果你源系统已用 400GB，那就非常紧张，最好先清理缓存、日志、旧内核、Docker 镜像、 snap 旧版本，把已用空间降到 350GB 以下再迁移。一个稳妥的经验公式是：源系统实际已用数据量 < 目标盘可用容量 × 0.8。比如目标盘可用 450GiB，源系统已用最好不超过 360GiB，这样系统还能有 20% 空闲空间，避免 ext4 碎片化严重和性能下降。

2.2 用三条命令摸清源盘底线

在源系统上先别急着做再生龙备份，先执行下面这几条命令，把容量、文件系统、分区表、LVM 结构全部看清楚。第一条是查看块设备整体布局：

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID

这条命令能一眼看出哪个是物理盘、哪个是分区、哪个是 LVM 逻辑卷，以及挂载点和 UUID。第二条是查看文件系统使用情况：

df -hT sudo du -xhd1 / | sort -h

df 看的是文件系统层面的已用和可用，du 看的是目录实际占用。很多时候 df 显示已用 300GB，du 加起来只有 220GB，差额可能是被删除但进程仍占用的文件，重启或清理后能释放。第三条是查看 ext4 文件系统的最小可缩小尺寸：

sudo e2fsck -f /dev/sda2 sudo resize2fs -P /dev/sda2

把 /dev/sda2 换成你的根分区或根逻辑卷。resize2fs -P 会输出文件系统最小块数，通常以 4K 块为单位，乘以 4 再除以 1024 就是 MiB。这个值告诉你根文件系统理论上最小能缩到多少。如果是 LVM，还要看：

sudo pvs sudo vgs sudo lvs sudo vgcfgbackup

vgcfgbackup 会把 LVM 元数据备份到 /etc/lvm/backup，缩卷前做一次，万一缩错了还有机会恢复元数据。

2.3 目标盘容量标称值与实际可用值的换算

买硬盘时看到的 512GB、1TB 是十进制标称值，操作系统里看到的是二进制 GiB。512GB 实际约 476.9GiB，1TB 实际约 931.3GiB。你还要减去分区表本身的开销，GPT 分区表通常占用 1MiB 到 2MiB，每个分区对齐到 1MiB 或 2048 扇区，几百 MiB 的 EFI 分区、1GiB 左右的 /boot 分区、8GiB 到 16GiB 的 swap 分区，这些都要从总容量里扣。如果你准备把 Ubuntu 迁到 256GB SSD，实际可用约 238GiB，扣掉 EFI 512MiB、/boot 1GiB、swap 8GiB，根分区最多 228GiB，再留 15% 空闲，源系统已用数据最好控制在 190GiB 以内。很多老机器 256GB SSD 装完 Ubuntu 和常用软件后已用 120GB 到 180GB，所以迁移是可行的，但前提是必须先把源盘根分区缩小到目标盘能容纳的尺寸。这个计算过程看起来琐碎，但能避免你折腾一晚上才发现根本装不下。

提示：目标盘如果是 NVMe 和 SATA 混用，分区表类型尽量保持一致。UEFI 启动的 Ubuntu 源盘通常是 GPT，目标盘也建议用 GPT；BIOS 启动的源盘可能是 MBR，目标盘如果强行用 GPT，旧主板可能无法引导。

3. 方案一：源端瘦身，把 Ubuntu 缩到目标盘能装下

3.1 ext4 根分区缩小：先文件系统后分区

缩小 ext4 分区的铁律是“先缩文件系统，再缩分区”，顺序反了会直接损坏文件系统。你需要在 Ubuntu Live USB 环境下操作，不要在当前运行的根分区上直接缩，因为根分区正在被挂载读写，resize2fs 会拒绝或导致数据损坏。制作一个 Ubuntu Live USB，启动后选择“Try Ubuntu”，打开终端，安装 gparted 和 lvm2：

sudo apt update sudo apt install gparted lvm2

假设源盘是 /dev/sda，根分区是 /dev/sda2，目标是把根分区缩到 220GiB。先检查文件系统：

sudo e2fsck -f /dev/sda2

然后缩小文件系统到 220GiB：

sudo resize2fs /dev/sda2 220G

注意，resize2fs 缩小文件系统时，目标尺寸必须大于文件系统最小尺寸，并且要留一定余量。缩完文件系统后，再用 GParted 图形界面缩小分区。打开 GParted，选中 /dev/sda2，右键选择“Resize/Move”，把分区大小调整为 220GiB，并且把分区起始位置保持不动，这样分区结束位置会往前移，释放出后面的空间。点击应用后，GParted 会调整分区表。如果你不习惯图形界面，也可以用 parted 或 fdisk，但 parted 缩分区时不会自动调整文件系统，风险更高，新手还是用 GParted 更稳。

3.2 LVM、swap 与 EFI 分区的处理顺序

如果 Ubuntu 安装时启用了 LVM，根分区通常是 /dev/mapper/ubuntu--vg-ubuntu--lv，底层是 /dev/sda3 这样的物理卷分区。缩小顺序是：先缩逻辑卷文件系统，再缩逻辑卷，再缩物理卷，最后缩分区。假设卷组叫 ubuntu-vg，逻辑卷叫 ubuntu-lv，先查看：

sudo lvs sudo vgs sudo pvs

然后缩小逻辑卷和其中的文件系统：

sudo lvreduce --resizefs -L 220G /dev/ubuntu-vg/ubuntu-lv

--resizefs 会先缩文件系统再缩逻辑卷，比较省心。缩完逻辑卷后，物理卷可能还有大量空闲空间，需要把物理卷缩小到实际使用大小：

sudo pvresize --setphysicalvolumesize 225G /dev/sda3

注意 pvresize 的尺寸要略大于逻辑卷实际占用，否则会报错。最后用 GParted 把 /dev/sda3 分区缩小到 225GiB。swap 分区如果不需要，可以在 /etc/fstab 里注释掉，然后删除 swap 分区，改用 swapfile。EFI 分区通常只有 100MiB 到 512MiB，不建议缩得太小，Ubuntu 的 EFI 分区建议保留至少 300MiB，如果目标盘实在紧张，可以保留 260MiB，但不要再小，否则未来内核更新可能写不进去。如果源盘有独立的 /boot 分区，通常 1GiB 到 2GiB，保留 1GiB 即可。所有分区缩完后，源盘尾部会多出未分配空间，这时候再用再生龙重新备份，备份出来的分区表就不会超出目标盘容量了。

3.3 收尾修复：fstab、GRUB 和 initramfs

源端瘦身完成后，不要急着拔盘启动，先检查 /etc/fstab 和引导配置。如果你删除了 swap 分区，要把 /etc/fstab 里对应的 UUID 行注释掉，或者改成 swapfile 的挂载项。如果根分区 UUID 没变，通常不需要改。但如果你在 GParted 里调整了分区，UUID 一般不会变，只有重新格式化才会变。确认 UUID：

sudo blkid cat /etc/fstab

如果 UUID 有变化，更新 /etc/fstab。然后重新生成 initramfs，确保新分区布局被正确识别：

sudo update-initramfs -u sudo update-grub

如果是 BIOS 启动，可以重装 GRUB 到磁盘：

sudo grub-install /dev/sda

如果是 UEFI 启动，确保 EFI 分区挂载在 /boot/efi，然后执行：

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

这些操作需要在 chroot 环境下进行，如果你是在 Live USB 里缩分区，要先挂载源系统根分区和必要目录，再 chroot 进去执行。步骤稍微繁琐，但能避免迁移后开机失败。缩分区本身就是高风险操作，建议先做一次完整的再生龙备份，再动手缩小。如果缩分区过程中断电，源盘可能直接损坏，所以笔记本要插电源，台式机最好接 UPS。

4. 方案二：再生龙专家模式恢复，跳过磁盘大小检查

4.1 -icds、-k0、-k1、-r 到底怎么选

再生龙的专家模式里有一堆参数，很多人看到就晕。和硬盘大小限制最相关的是这几个：-icds 表示跳过检查目标硬盘大小是否大于源硬盘，-k0 表示不创建分区表，沿用目标盘现有分区表，-k1 表示使用源盘分区表创建目标盘分区，-k2 表示用 dd 复制分区表，-r 表示恢复后调整文件系统大小以填满分区。目标盘小于源盘时，最危险的组合是“-icds + -k1”，因为虽然跳过了检查，但源分区表仍然可能超出目标盘容量，创建分区时就会失败。比较稳的思路是“手动在目标盘创建好较小的分区表，然后用 -k0 恢复到现有分区”，或者先用方案一把源盘缩到小于目标盘，再用“-k1 + -r”恢复到目标盘。如果目标盘和源盘容量相同或更大，-k1 + -r 是最省事的，恢复后分区会自动扩展填满磁盘。如果目标盘更小，千万别指望 -icds 单独解决问题，它只是跳过检查，不负责重新规划分区。

4.2 手动在目标盘建分区再恢复分区

这条路线适合不想动源盘，或者源盘数据太重要不敢缩的情况。先把目标盘接到机器上，用 Ubuntu Live USB 启动，打开 GParted，给目标盘创建 GPT 分区表，然后按目标盘容量手动创建 EFI 分区、/boot 分区、根分区、swap 分区。比如目标盘 476GiB，可以这样规划：EFI 512MiB，/boot 1GiB，swap 8GiB，根分区剩余全部约 466GiB。如果你源系统根分区已用 200GiB，466GiB 完全够用。创建完分区后，不要格式化根分区，保持空白即可，因为再生龙恢复分区时会写入文件系统。如果你手动格式化了，也没关系，恢复时再生龙会覆盖。然后启动再生龙，选择 device-image 模式，找到之前保存的镜像，选择 restoreparts 恢复分区模式，在专家模式里勾选 -k0，不创建分区表，把源系统的根分区恢复到目标盘的根分区，EFI 分区恢复到目标盘 EFI，/boot 恢复到目标盘 /boot。注意分区的对应关系要选对，源盘 /dev/sda2 对应目标盘 /dev/sdb2 这种，别选反了。恢复完成后，目标盘的分区表是你手动创建的小分区表，不会受源盘大分区表影响。这个方案的关键是手动分区时目标分区容量必须大于源分区已用数据量，否则恢复到最后会提示 no space left on device。

4.3 整盘恢复失败后的分区恢复路线

如果你已经尝试过整盘恢复并失败，目标盘可能被写入了残缺的分区表。这时候先别慌，重新用 Live USB 启动，打开 GParted，删除目标盘所有分区，重新创建 GPT 或 MBR 分区表，然后按上一节的方法手动创建小分区。如果再生龙镜像里保存的是整盘信息，你也可以只恢复分区，不恢复整盘。在再生龙恢复菜单里选择“restoreparts”而不是“restoredisk”，然后逐个选择要恢复的分区。恢复根分区时，如果源根分区是 LVM 逻辑卷，再生龙可能把它保存为 lvm 相关的镜像，恢复时目标盘也要有对应的 LVM 结构，或者你选择恢复到普通分区，但这样需要额外修复 LVM 配置。更简单的做法是：在目标盘上先创建和源盘一致的 LVM 结构，再恢复逻辑卷。比如目标盘 /dev/sdb3 创建为物理卷，加入卷组 ubuntu-vg，创建逻辑卷 ubuntu-lv，然后再生龙恢复到该逻辑卷。恢复完成后，目标盘的分区表是你自己建的，逻辑卷大小也是你控制的，不会超出目标盘。整盘恢复失败后走分区恢复路线，虽然步骤多，但可控性最强，尤其适合源盘和目标盘容量差异较大的场景。

5. 方案三：绕开块级克隆，用文件级迁移更省心

5.1 rsync 迁移 Ubuntu 的完整命令与排除项

如果你不想缩源盘，也不想和再生龙的分区表较劲，文件级迁移是最灵活的方案。它的思路是把源系统文件复制到目标盘的新文件系统里，然后重建引导。目标盘可以比源盘小很多，只要文件总量装得下。先用 Live USB 启动，给目标盘分区格式化：EFI 分区 FAT32，根分区 ext4，/boot 分区 ext4，swap 分区 swap。然后挂载目标盘根分区到 /mnt/newroot，挂载 EFI 到 /mnt/newroot/boot/efi，挂载 /boot 到 /mnt/newroot/boot。挂载源系统根分区到 /mnt/source，如果源系统有独立 /boot 和 EFI，也挂载上。然后执行 rsync：

sudo rsync -aAXHv --delete \ --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} \ /mnt/source/ /mnt/newroot/

-a 表示归档模式，保留权限、时间戳、符号链接；-A 保留 ACL；-X 保留扩展属性；-H 保留硬链接；-v 显示进度。排除项里 /dev、/proc、/sys、/tmp、/run 是运行时目录，不需要复制；/mnt、/media 挂载点也不需要。复制完成后，还要处理 /etc/fstab，把里面的 UUID 改成目标盘新分区的 UUID。用 blkid 查看新分区 UUID，然后编辑 /mnt/newroot/etc/fstab。接着 chroot 进去重建引导：

sudo mount --bind /dev /mnt/newroot/dev sudo mount --bind /proc /mnt/newroot/proc sudo mount --bind /sys /mnt/newroot/sys sudo chroot /mnt/newroot

在 chroot 环境里执行：

blkid nano /etc/fstab update-initramfs -u grub-install /dev/sdb update-grub exit

如果是 UEFI，grub-install 命令换成：

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

文件级迁移的好处是目标盘分区可以任意小，只要装得下文件。缺点是会丢失一些块设备相关的元数据，比如 LVM 配置、磁盘 UUID、部分内核模块参数，但大多数普通 Ubuntu 系统都能这样迁移成功。迁移前最好把源系统里不用的东西清理掉，比如 /var/cache/apt/archives、旧内核、Docker 镜像、 snap 缓存、日志文件，能省出几十 GB。

5.2 tar 打包迁移和引导重建

tar 是另一种文件级迁移方式，适合把整个系统打包成一个压缩包，再解压到目标盘。命令如下：

sudo tar -cpf /mnt/backup/ubuntu-root.tar \ --exclude=/proc --exclude=/sys --exclude=/dev \ --exclude=/run --exclude=/tmp --exclude=/mnt \ --exclude=/media --exclude=/lost+found /

这里假设你已经把源系统根分区挂载到了 /，并且 /mnt/backup 是外接备份盘。打包完成后，在目标盘上格式化并挂载根分区到 /mnt/newroot，然后解压：

sudo tar -xpf /mnt/backup/ubuntu-root.tar -C /mnt/newroot

解压后同样要更新 /etc/fstab、重建 initramfs、安装 GRUB。tar 迁移和 rsync 迁移本质一样，都是复制文件，区别是 tar 会保留更多归档属性，但速度可能慢一些，尤其是大量小文件。如果源系统有 SELinux 或 AppArmor 策略，tar 解压后可能需要重新标记，Ubuntu 默认 AppArmor 通常问题不大。文件级迁移还有一个隐藏好处：它不关心源盘是 MBR 还是 GPT，也不关心源盘分区有多大，你只要在目标盘上创建合理的分区表，然后复制文件即可。对于“再生龙移植 Ubuntu 硬盘大小限制”这个场景，文件级迁移往往是最终兜底方案，成功率很高。

5.3 临时大盘中转：先恢复再缩小

如果你既想用再生龙，又不想在源盘上冒险缩分区，可以找一块容量大于等于源盘的大硬盘做中转。比如源盘 1TB，目标盘 512GB，先找一块 1TB 或 2TB 的临时硬盘，用再生龙把源盘整盘恢复到临时盘上，这一步不会遇到大小限制。然后从临时盘启动 Ubuntu，或者用 Live USB 挂载临时盘，用 GParted 把临时盘上的根分区缩小到 400GB 以内，删除多余的 swap 或调整分区布局。缩完后，再用再生龙把临时盘备份成新镜像，这时候新镜像的分区表已经变小了，恢复到 512GB 目标盘时就不会再触发硬盘大小限制。这个方案适合手头有临时大硬盘或虚拟机存储的场景，也适合在 VMware 虚拟机安装 Ubuntu 后做系统迁移：先在虚拟机里把虚拟磁盘扩容，恢复到虚拟磁盘，缩小，再克隆到物理小盘。中转方案的缺点是耗时，需要两次备份两次恢复，但数据安全性最高，因为源盘全程只读，没有缩分区风险。如果你用的是服务器或工作站，还可以把临时盘挂到另一台机器上操作，减少对生产环境的干扰。

6. 常见问题排查速查表与实操避坑心得

6.1 报错信息与对应处理

表格里的问题我几乎都遇到过，尤其是 emergency mode 和 GRUB rescue。最容易被忽略的是 fstab UUID：再生龙恢复后，如果目标盘分区重新创建，UUID 大概率会变，但 /etc/fstab 还是旧的，系统启动时找不到根分区，就会掉进 emergency mode。解决办法很简单，用 Live USB 启动，挂载目标盘根分区，编辑 /etc/fstab，把 UUID 换成 blkid 输出的新值。另一个高频问题是根分区没有扩展，恢复后根分区只用了 220GiB，目标盘其实有 466GiB，剩余空间白白浪费。这时候用 growpart 扩展分区，再 resize2fs 扩展文件系统：

sudo growpart /dev/sdb 2 sudo resize2fs /dev/sdb2

如果是 LVM，先扩展逻辑卷和文件系统：

sudo lvextend -l +100%FREE --resizefs /dev/ubuntu-vg/ubuntu-lv

注意顺序：普通分区是先扩分区再扩文件系统，LVM 是先扩逻辑卷再扩文件系统，lvextend --resizefs 会自动处理。

6.2 我踩过的坑和独家建议

第一个坑是“边运行系统边缩根分区”。我第一次尝试缩根分区时，直接在运行中的 Ubuntu 里执行 resize2fs，结果提示文件系统忙，强行用 -f 参数后文件系统直接损坏。后来才知道必须用 Live USB 启动，在未挂载根分区的情况下操作。第二个坑是“只缩文件系统不缩分区”。resize2fs 把文件系统缩到 220G，但分区还是 900G，再生龙备份时仍然按 900G 分区表保存，恢复到小盘照样失败。必须用 GParted 把分区也缩到 220G 左右，让分区表尺寸和文件系统尺寸匹配。第三个坑是“忽略 LVM 的 pvresize”。缩了逻辑卷，但物理卷还占着整块盘，分区表还是大的。必须依次缩逻辑卷、缩物理卷、缩分区，三层都缩完才行。第四个坑是“目标盘分区表类型选错”。源盘是 UEFI/GPT，目标盘用 MBR，恢复后 UEFI 固件找不到 EFI 分区，系统无法启动。迁移前先确认源盘是 UEFI 还是 BIOS，用[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS查看，目标盘分区表保持一致。第五个坑是“忘了更新 initramfs”。迁移后内核模块和分区 UUID 变化，如果不执行 update-initramfs -u，启动时可能找不到根文件系统。第六个坑是“在双系统 Windows 快速启动开启时操作”。Windows 的快速启动和休眠会让 NTFS 分区处于脏状态，GParted 无法安全调整，甚至可能损坏 Windows。迁移前先在 Windows 里关闭快速启动和休眠。第七个坑是“没有留足空闲空间”。目标盘根分区装到 95% 以上，ext4 性能急剧下降，日志写入也容易失败。建议根分区使用率控制在 80% 以内。第八个坑是“再生龙镜像保存到源盘本身”。如果源盘快满了，镜像没地方放，备份到一半失败。用外接 USB 硬盘或网络共享存放镜像，确认空间足够。第九个坑是“恢复后直接拔 U 盘重启”。有些主板会把 U 盘启动项排在硬盘前面，重启又进了安装环境。恢复完成后先拔掉 U 盘，再重启。第十个坑是“没有验证备份”。再生龙备份完成后，最好用“检查镜像”功能验证一次，或者恢复到虚拟机里启动测试。备份文件损坏但迟迟没发现，等源盘坏了再恢复就来不及了。

注意：再生龙整盘恢复适合同容量或更大容量的目标盘，跨容量尤其是目标盘更小时，优先考虑源端瘦身或文件级迁移。不要为了省事只勾选 -icds，它不解决分区表超界的问题。

如果你经常做 Ubuntu 系统迁移，我建议把流程固定下来：先核算容量，再备份源盘，然后在 Live USB 里缩分区或做文件级复制，最后重建引导并验证。对于 VMware 虚拟机安装 Ubuntu 的场景，可以先把虚拟机磁盘扩容到大于源盘，恢复后再缩虚拟磁盘，或者直接在虚拟机里用 rsync 迁移到新虚拟磁盘。对于物理机，准备一个 Ubuntu Live USB 和一个再生龙 U 盘，基本能覆盖所有迁移需求。再生龙在批量部署和同容量克隆时非常高效，但跨容量迁移时，文件级方案更灵活，也更不容易被分区表卡住。最后再分享一个我常用的小技巧：在正式动目标盘之前，先用一块移动硬盘做一次“缩小后恢复”演练，把启动、登录、网络、休眠都跑一遍，再往正式盘上写。这样即使翻车，代价也只是重来一次演练，而不是把唯一的生产系统弄丢。