系统镜像制作实战：从dd到Clonezilla的Linux/Windows迁移指南

1. 做 img 镜像之前，先把思路理清楚

很多人一听到“制作系统镜像”，第一反应就是打开某个工具点两下，等着导出文件。实际上，img 格式的系统镜像跟日常用的装机 ISO 完全不是一回事，它更像是对整块磁盘做了一次“完整复印”，里面包含了操作系统、引导程序、分区表、文件系统乃至硬件驱动信息。你做的任何一个多余操作，或者系统里残留的脏数据，都会原封不动地带进镜像里，直接影响后续启动是否顺利。

我平时接触最多的三个场景，基本能覆盖 90% 的需求：一是把一台物理服务器迁移到虚拟机，二是给团队制作统一开发环境的“黄金镜像”（Golden Image），三是把定制好的 Linux 系统做成 img 文件，方便写入其他磁盘或者批量部署到多台设备。无论你属于哪一种，下面这套方法论都适用：整体规划优先、制作前做减重、制作后做验证。请记住这十二个字，它能帮你避开绝大多数坑。

另外还要想清楚一个问题：你要的是“整盘镜像”还是“单分区镜像”。整盘镜像包含 MBR/GPT 引导信息，适合迁移和写盘；单分区镜像通常只备份根分区或数据分区，适合做软件备份、环境模板。两者的制作命令和后续处理方式差异很大，我后面会分别讲到。

2. 核心工具准备与关键参数详解

制作 img 镜像，本质上是对磁盘做完整或分区的复制，因此工具选择非常关键。不同的操作系统和不同的目标场景，工具选型完全不同。

2.1 一个干净的 Linux 环境和一个 mount 点

如果你要制作的系统本身是 Linux，最推荐的制作环境是另一台 Linux 宿主机，或者一张能启动的 Linux 安装盘进入急救模式。为什么要强调“干净”？因为制作镜像的过程中，被制作系统的分区不能处于挂载并被频繁读写的状态，否则会复制到不一致的数据，导致镜像内文件系统损坏。

我踩过最大的一个坑，就是在原系统运行状态下直接对根分区执行 dd。结果做出来的镜像虽然能引导，但文件系统需要强制 fsck，部分服务启动异常。后来学乖了，制作镜像前一定把系统停到一个稳定状态——能卸载的分区全部卸载，能关的服务全部关掉，尽量用另一个系统来操作目标磁盘。

在 Linux 环境中准备一个 mount 点也很重要，一般用/mnt/sysimage这种路径。挂载分区检查、修改配置，都需要这个临时目录。如果你做的是虚拟机内部磁盘的 img 文件，还需要你有足够的磁盘空间来存放这个 img 文件，至少在目标磁盘已用空间的两倍以上，因为这些操作会产生临时文件和中间产物。

2.2 dd 命令的完整语法与参数计算

Linux 下最基础、最底层的镜像制作工具就是 dd。它的工作方式非常直接：从输入文件读取数据，原样写入输出文件。如果输入文件是一块磁盘设备，输出文件是一个普通文件，那你得到的就是一块磁盘的完整镜像。

一条完整的整盘 dd 命令通常长这样：

dd if=/dev/sda of=/mnt/backup/system.img bs=4M status=progress conv=sync,noerror

这里每个参数都有讲究：

• if指定输入设备，/dev/sda是你要镜像的整块磁盘。
• of指定输出文件，/mnt/backup/system.img是镜像存放路径。
• bs是块大小，设成 4M 或者 16M 能明显加快拷贝速度，因为减少了寻道次数和系统调用。
• status=progress是让你能实时看到复制进度和速度。
• conv=sync,noerror表示遇到读取错误时补零继续，而不是中断，这在磁盘有坏道时能救回大部分数据。不过如果你想要一个严格纯净的镜像，我建议去掉noerror，宁可它报错停止，也不要默默补零，免得后续启动时出现诡异问题。

不少人会纠结块大小选择。对于现代磁盘来说，bs=64K、bs=1M、bs=128M之间的性能差异已经很小，我实测下来bs=4M在绝大多数 Linux 发行版上效率最高。如果你对性能敏感，可以先跑一条dd if=/dev/sda of=/dev/null bs=4M status=progress来测一下源盘读取速度，心里有个底。

关于镜像大小的计算，这里有个重要概念要区分开：分区已用空间和分区大小。dd 复制的是整块磁盘的物理内容，所以system.img的大小会等于源盘的总容量，而不是系统实际占用的空间。比如你一块 500G 的盘，系统只用了 50G，dd 出来的镜像仍然是 500G。这是 dd 模式最让人头疼的地方——镜像文件非常大且无法直接缩小。解决办法是后面结合qemu-img做格式转换和压缩，或者改用 Clonezilla 这类按已用数据备份的工具。你如果对镜像体积有要求，在这里就要做选型判断了。

2.3 制作过程中为什么需要先挂载清理

制作镜像前，挂载到 Linux 环境中的源分区需要做几件准备工作。很多人直接开拷，做完镜像后发现各种奇怪问题：其实不是镜像本身有问题，而是源系统本身就带着一堆“垃圾”进了镜像。

第一件事是清理临时文件和日志。Linux 下的/tmp、/var/tmp、/var/log里往往堆积了大量无用数据。日志这东西在开发环境里没什么用，但在镜像里会越积越多，做成镜像既不干净又撑大体积。比较稳妥的做法是：挂载后在目标根目录里执行清理命令，清掉包管理器缓存、旧内核、临时文件。

第二件事是检查磁盘剩余空间。你制作的镜像文件要放在另一个磁盘或分区上，这个位置的剩余空间必须大于源盘的总容量。如果是多分区系统，比如/boot单独分区、根分区、home 分区分开的情况，dd 纯整盘方案会把你所有分区一股脑全部装进镜像。有机会的话，我会在下一章演示一个更优雅的方案——用 Clonezilla 只备份必要的分区。

第三件事是处理网卡和主机标识。Linux 系统在首次启动时会根据网卡 MAC 地址生成 udev 规则，如果你把镜像部署到另一台机器上，网卡名可能会从eth0变成ens33，甚至出现网络无法启动的情况。虽然 Ubuntu/CentOS 的新版本已经不用/etc/udev/rules.d/70-persistent-net.rules，但你依然要留意系统里固化了哪些硬件信息。对于 Windows 系统，这个问题更严重，会在第四章单独讲。

3. 实操过程：从正在运行的系统打包出可用的 img

不同系统和不同场景需要不同的制作流程，下面我会分三种情况来讲：整盘 dd 方案、Clonezilla 分区备份方案、Windows 转虚拟机方案。这三种方案覆盖了绝大多数个人和团队的使用场景。

3.1 在 Linux 宿主上用 dd 制作 raw 格式镜像

这是最经典也是我平时最常用的一种方式。它特别适合：源系统是一台 Linux 物理机或云主机，你想把它整体迁移到 VMware/KVM 这类虚拟化平台，或者你想把整个系统存档，随时可以完整恢复。

制作步骤大概如下：

1. 准备一台 Linux 宿主机，插上目标源盘（通过 USB 硬盘盒转接也行），确保系统能识别到它。假设识别为/dev/sdb。
2. 在宿主机的存储空间上创建一个目录，比如/data/img_output。
3. 先确认盘符和分区情况，避免拷错盘。用fdisk -l或lsblk查看，找到目标盘的正确盘符。

lsblk # 输出类似： # NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT # sdb 8:16 0 232.9G 0 disk # ├─sdb1 8:17 0 512M 0 part # ├─sdb2 8:18 0 232.4G 0 part

4. 执行整盘 dd：

sudo dd if=/dev/sdb of=/data/img_output/my-system.img bs=4M status=progress

5. 耐心等待。一块 500G 机械硬盘全盘复制可能要一两个小时，如果是 NVMe 固态，速度会快得多，大约十分钟到二十分钟。

6. 复制完成后，使用sync命令确保缓存落盘，然后对镜像文件做一次完整性检查：

sync sudo fdisk -l /data/img_output/my-system.img

fdisk -l能直接识别 img 文件里的分区表，如果能正常列出分区，说明镜像头部数据完整。我再强调一句：dd 出来的原始 img 文件，大小和源盘一模一样，直接拿去用没问题，但如果你要传到网盘、分发给别人，建议先压缩。压缩命令放在第四章，因为涉及格式转换和体积优化。

3.2 用 Clonezilla 做分区镜像，备份与恢复细节

Clonezilla 是我非常推荐的一个工具，它最大的优势是“只备份已用数据”，生成的文件体积远小于 dd 整盘镜像，而且恢复时可以自由选择恢复到更大或更小的目标分区，不用被源盘大小绑定。它适合的场景主要有：给团队做统一开发环境模板、备份系统分区、在异机间迁移 Linux 系统。

使用 Clonezilla 的方式有两种：一种是下载它的 ISO 做成启动盘，启动后按菜单操作；另一种是在现有 Linux 里安装clonezilla包，通过命令行执行。我通常用前者，因为制作镜像时源系统应该是离线状态，启动盘方案最安全。

关于 Clonezilla 的专业模式，你需要了解几个关键菜单的含义：

• device-image：把分区或整盘保存成一个镜像文件。
• device-device：直接磁盘对拷，相当于磁盘克隆。
• 选择“专家模式”（Expert Mode）后，可以控制压缩选项、检查镜像、是否分割存储等。
• 保存格式可以选择-q1或-q2，分别对应不同的压缩比例和速度。

用 Clonezilla 备份 Linux 系统时，我强烈建议把/boot分区单独勾选，并把根分区一同备份。恢复的时候，先恢复根分区，再恢复/boot，顺序不对会导致引导失败。另外要注意，Clonezilla 生成的镜像是一个包含多个文件的文件夹，不是单一 img 文件，如果你想得到的是纯 img 文件，后面还需要用qemu-img convert把 Clonezilla 镜像转换成 raw 格式。虽然多了一步，但在批量部署场景下，Clonezilla 的方案远优于 dd。

3.3 把 Windows 系统做成 img，并让它在 VMware 里跑起来

把 Windows 物理机做成 img 再塞进虚拟机里跑，是很多人最想实现的操作。但这个流程比 Linux 复杂得多，因为 Windows 对硬件抽象层（HAL）的变化非常敏感：主板的 ACPI 接口、存储控制器、显卡驱动，任何一个不匹配都可能导致蓝屏0x0000007B（Inaccessible Boot Device）。

我个人的经验是：除非万不得已，不要直接用 dd 把 Windows 物理盘做成 img 再启动。正确路线是用 VMware 自带的 vCenter Converter，或者用 Disk2vhd 把 Windows 系统转成 VHD/VHDX 格式，然后再用 qemu-img 转成 img。整体步骤是这样的：

1. 在 Windows 物理机上运行 Sysprep 工具，这个工具位于C:\Windows\System32\Sysprep\sysprep.exe。选择“进入系统全新体验（OOBE）”，勾选“通用”，关机选项选“关机”。Sysprep 会重置系统唯一标识（SID）、清除事件日志，并让 Windows 在下次启动时重新枚举硬件，这是 Windows 镜像能够跨硬件迁移的关键。

2. 用 Disk2vhd（微软官方工具）把正在运行的物理磁盘转换成 VHDX 文件。这个工具支持在系统运行时在线转换，不要求关机。如果系统盘较大，建议输出目录放在另一块物理磁盘上。

3. 把生成的 VHDX 拷贝到装有 VMware 的宿主机上，新建虚拟机，磁盘类型选 SATA 或 SCSI 都行，先不要启动，把虚拟机的磁盘文件指向该 VHDX。

4. 打开虚拟机的 VMX 配置文件，在文件末尾加入一行：

ide0:0.returnToBios = "false"

这个参数很重要，否则 VMware 可能会因为找不到启动设备而卡住。如果是 SCSI 控制器启动，则在 VMX 里加入：

scsi0:0.returnToBios = "false"

5. 启动虚拟机，这时 Windows 会自动安装新硬件驱动并重启数次，耐心等待完成即可。

如果你真的只能拿到一个 img 文件（比如同事给你拷了一个），那也可以通过 VMware 的“转换物理机”功能或者直接新建虚拟机选择“使用现有虚拟磁盘”来加载。实测下来，img 格式可以被 VMware Workstation 直接识别并挂载，但如果启动蓝屏，大概率是缺少适当驱动或硬件抽象层不匹配，这种问题的排查我会在第六章里细讲。

3.4 镜像压缩与格式转换，让 img 文件“瘦身”并跨平台使用

dd 出来的 raw img 文件动辄几百 GB，不适合存储和传输。我一般会用qemu-img工具把它转换成qcow2格式或者进行压缩。qemu-img 是 QEMU/KVM 虚拟化套件里的一个命令行工具，也可以独立安装在各种 Linux 发行版里。

先安装依赖，在 Ubuntu/Debian 上：

sudo apt install qemu-utils

CentOS/RHEL 系：

sudo yum install qemu-img

最常用的是这条命令，把 raw 格式转成 qcow2 并启用压缩：

qemu-img convert -f raw -O qcow2 -c my-system.img my-system.qcow2

如果想要受限大小的镜像，并且源分区是 ext4/xfs，还可以用truncate或qemu-img resize先缩小文件系统，再转换。这里要注意，resize 是有条件限制的，只能在文件系统支持缩容的前提下进行，而且必须先缩文件系统，再缩镜像文件，顺序反了就会损坏数据。我一般习惯这样操作：

1. 先挂载镜像内的根分区。
2. 用resize2fs把文件系统缩到最小。

sudo resize2fs -M /dev/mapper/loop0p1

3. 用e2fsck -f检查文件系统一致性。
4. 卸载分区，使用qemu-img resize把镜像缩到文件系统实际大小加上少量余量。
5. 最后再转 qcow2 并压缩。

这样处理之后，原本一个 60G 的 Linux 系统镜像，通常能缩到 2-4G 的 qcow2 文件。如果你需要的是 img（raw）格式，最后再转回去即可：

qemu-img convert -f qcow2 -O raw my-system.qcow2 slim-system.img

4. 制作镜像的优化与兼容性处理

很多新人做出来的镜像能启动，但在不同硬件或虚拟平台上跑起来总出问题。这一章就是专门解决这些“看起来能用，但用得不爽”的情况。

4.1 为什么要先改系统配置再做镜像

有一类问题，制作时不会立刻暴露，等镜像部署到新机器才会爆发：比如网卡起不来、SSH 连不上、磁盘分区无法识别。根源基本都是制作前没有清理系统里的硬件绑定信息。

Linux 系统里，/etc/fstab记录着文件系统挂载表和分区的 UUID。当你把系统迁移到新磁盘时，如果分区 UUID 变了，启动时会卡在mount阶段或者进入紧急模式。因此，在制作镜像前，我建议先记录一下分区 UUID：

blkid /dev/sda1

然后把/etc/fstab里的挂载项改成用 LABEL（卷标）或者改为相对路径引用。如果你不确定怎么改，最稳妥的办法是保留 UUID 不变，即制作镜像时保持分区顺序和分区表结构与原盘一致，这正好是 dd 整盘方案的优势——分区表、UUID、文件系统结构完全原样复制。

如果你要做的是部署到多种硬件的通用镜像，那么fstab里还需要确认没有写死设备名（比如/dev/sda），尽量使用UUID或LABEL引用。另外，/etc/udev/rules.d/70-persistent-net.rules这种文件如果存在，直接删掉，让系统重新生成。我在 CentOS 7 上就遇到过网卡从eth0变成enp2s0导致网络脚本失效的问题，删除后重启即可恢复。

Windows 系统更麻烦，参考 3.3 节的 Sysprep 流程。这里再强调一句：Sysprep 必须在系统未加入域且以管理员身份运行时才有意义，如果你在制作镜像前忘了跑 Sysprep，那么每个从同一镜像部署出去的 Windows 都会拥有相同的 SID，在域环境中会出现各种权限和身份冲突问题。虽然在一些小规模场景下不跑 Sysprep 也能用，但这是个定时炸弹，强烈建议养成习惯。

4.2 解决引导问题：MBR、EFI、grub 修复

哪怕你镜像制作步骤完全正确，也很难保证目标机器的引导方式和源机器一致。比如源盘是 MBR 传统 BIOS 引导，目标虚拟机是 UEFI 引导，镜像就会直接启动不了。这个场景在 VMware 里非常常见，所以我一般把引导问题分成两类来排查。

第一类是 MBR 引导。如果你用 dd 做了整盘镜像，恢复后 MBR 区域应该也恢复了。如果引导还是起不来，通常是因为 GRUB 的配置文件引用的是旧磁盘设备名，比如旧的grub.cfg里写着root=UUID=xxx，而目标系统的 /boot 分区 UUID 变了。修复方法是用系统安装盘启动进入急救模式，chroot 到目标系统，重新安装 GRUB。在 Ubuntu 上：

grub-install /dev/sda update-grub

在 CentOS/RHEL 上：

grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg

第二类是 EFI 引导。UEFI 启动依赖 EFI 分区中的引导文件，以及 NVRAM 启动项。如果你做的是整盘 dd 镜像，EFI 分区也会被包含，但目标机器的 NVRAM 里没有指向该 EFI 分区的启动项。解决办法是进入目标机器的 UEFI 设置里添加启动项，或者在系统内用 efibootmgr 手动创建。在 Linux 中可以使用：

efibootmgr -c -d /dev/sda -p 1 -L "MyLinux" -l \\EFI\\ubuntu\\shimx64.efi

这是我修复 EFI 引导最常用的命令，-p 1表示 EFI 分区是第一个分区，-l指定引导文件路径，不同发行版路径不同，Ubuntu 一般是shimx64.efi，CentOS 是shimx64.efi或grubx64.efi。如果你对这类命令不熟悉，最稳妥的办法是用安装盘的“尝试/救援模式”工具自动修复。

4.3 Windows 系统镜像的体积优化与 SID 重置

Windows 系统盘的静态体积通常很大，光是一个C:\Windows目录就轻松超过 20G。做镜像前如果不做瘦身，制作出来 img 文件会非常庞大，传输同步都是问题。我自己在给团队做 Windows 开发环境镜像时，会执行下面这些操作：

• 关闭系统还原、休眠功能，删除hiberfil.sys（使用powercfg /h off）。
• 运行磁盘清理工具，清理系统临时文件和 Windows 更新缓存。
• 使用vssadmin delete shadows /all删除所有系统还原点。
• 卸载不需要的预装应用和第三方软件。
• 清理用户目录下的下载文件、临时文件。

对于 Windows 10/11 系统，镜像原生体积已经非常大，即使压缩也不是很理想。我的建议是至少分两个版本：一个基础版（只安装操作系统和必要驱动），一个完整版（包含团队常用开发工具）。基础版用于快速部署，完整版用于开发者日常使用，两者用同一个 Sysprep 流程处理，部署效率会高很多。

SID 重置是 Windows 镜像最容易被忽略的问题。直接复制 Windows 系统而不做 Sysprep，会导致所有复制出来的系统 SID 相同。SID 相同在域环境下几乎无法使用——新机器无法加入域，或者加入后账户权限会互相干扰。Sysprep 的“通用”选项就是专门解决这个问题的。另外 Sysprep 之后，Windows 下次启动会重新进入 OOBE，这意味着你需要重新创建本地管理员账户。如果你希望部署时能自动配置，可以使用unattend.xml应答文件配合 Sysprep 实现全自动配置，这块内容比较多，我后续会单独写一篇，这里先留个引子。

5. 验证与使用场景：从 img 到实际运行

镜像做完了，别急着分发或写盘，先花点时间验证它能不能正常启动。任何跳过验证的镜像部署都是耍流氓——你永远不知道哪一步会出错。

5.1 用 VMware/QEMU 验证镜像

最方便的验证方式是把镜像直接加载到虚拟机里测试。对于 raw 格式的 img 文件，VMware Workstation 可以直接识别。新建虚拟机时，硬盘类型选 SATA，然后选择“使用现有虚拟磁盘”并指向 img 文件，启动即可。

如果不想新建虚拟机，也可以用 QEMU 快速启动。QEMU 的优点在于它能把 img 文件直接当作磁盘设备来用，并且支持多种格式，包括 raw、qcow2、vdi、vmdk。一条很简单的命令：

qemu-system-x86_64 -m 2048 -hda my-system.img -boot c -net nic -net user

加-enable-kvm可以启用硬件加速，跑起来会流畅不少。

验证时需要重点检查这几个项目：能否正常引导进入系统、磁盘挂载是否全部正常、网络接口是否启用并能获取 IP、关键服务（SSH、数据库、Web 服务）是否自动启动。如果这些都没问题，镜像基本可以认为合格。如果出现引导异常，按第四章的排查思路去处理，再重新生成镜像，不要在坏镜像上打补丁相信能侥幸成功。

5.2 把 img 写入物理磁盘，用于整机替换或批量部署

img 文件最典型的用途之一就是写入物理磁盘，做成一张可启动的移动硬盘或者替换原来系统盘。Linux 下写入镜像的命令非常简单，但也是一个容错率极低的操作。确认目标盘后再执行，一旦写错，数据全没。

sudo dd if=my-system.img of=/dev/sdb bs=4M status=progress conv=sync

写入完成后拔盘前先执行sync。如果目标磁盘小于源盘，dd 会直接报错，这个没办法绕过去，只能先把目标盘换大容量。写入后首次启动有可能会因为磁盘分区表没有完全对齐导致性能降低，但不影响使用。如果你用的是 UEFI 引导，还需要确认目标机器设置成从你写入的那块磁盘启动。

生产环境我一般不建议在线 dd 写入正在运行的机器，因为写入过程中系统可能产生 I/O，造成数据不一致。我惯用的做法是：准备一个带 Linux 的 Live USB 启动环境，在 Live 环境里完成写入。这样能保证目标磁盘没有挂载，镜像一致性最好。

5.3 镜像部署后的网络与安全设置

这一步经常被忽略，但恰恰是镜像“千人千面”的关键。从同一个镜像分发出多台机器后，每台机器的 hostname、IP、SSH 密钥、机器 ID 如果完全一样，轻则网络冲突，重则无法同时接入同一网络。

Linux 系统里需要重点修改的有：

• /etc/hostname：改成每台机器自己的主机名。
• /etc/machine-id：删除或重新生成，这是 systemd 用来标识机器的唯一 ID。U 和机器不同，务必重置。
• SSH 主机密钥：位于/etc/ssh/ssh_host_*，直接删除并重启 SSH 服务让它重新生成。
• 云平台还需要修改唯一标识，比如 cloud-init 的/etc/machine-id和/var/lib/cloud/instance。

Windows 系统则是通过 Sysprep 自动处理主机名和 SID，开机后你只需要手动设置计算机名和网络配置即可。做镜像分发前把这些配置统一清理干净，部署完的机器舒适度会高很多。

6. 常见问题与排查技巧实录

最后把我在多年实操中遇到的高频问题整理成表，方便你快速定位。这些坑我都踩过，没有一个是纸上谈兵。

排查问题有一条基本原则：不要光看症状，要追根因。启动失败先确认到哪一步失败：是 BIOS/UEFI 自检前失败、引导加载器失败、内核启动失败还是用户态服务失败。最简单的办法是看启动时屏幕最后一行输出，或者接串口看日志。虚拟机里就通过 VMware 的虚拟串口把内核输出导出来，物理机就只能靠显示器和耐心了。

个人经验里，最有用的排查工具是一个能启动的 Linux Live USB，再加上一份源系统的安装盘。无论是修复 GRUB、chroot 修改配置、还是重新生成 initramfs，都能在 Live 环境完成。目前很多发布版提供“救援模式”，本质上就是这个思路。遇到不严重的问题，别急着重做镜像，先进 Live 环境看看配置有没有救。

另外，制作大镜像时建议把源盘碎片整理干净。Windows 下可以用contig或系统自带的碎片整理；Linux 的 ext4 碎片化影响不大，但日志文件系统建议先执行fsck -f确保文件系统无错。一个带文件系统错误的镜像，放到哪都是隐患。

最后，几条个人忠告

我不建议你第一次做复杂镜像就直接照抄全流程，最好从一台测试虚拟机开始练手。在虚拟机上跑通 dd、转换、恢复、验证这一整套流程，你再迁移物理机就有底气了。

镜像命名也要养成良好习惯：系统名-架构-版本-日期-状态.img这种格式，比如ubuntu-22.04-amd64-20250115-base.img。做过镜像维护的朋友都明白，命名混乱的镜像目录就是一场灾难，三个月后你自己都分不清哪个能用哪个是半成品。

如果你做的镜像是长期要用的基础环境，记得给“基础版本”和“软件更新版本”分开维护，不要把日常更新直接覆盖到黄金镜像上，否则很容易把测试机上的脏数据带进正式镜像。我自己是固定三个月更新一次基础镜像，中间只做安全补丁和驱动更新，应用软件尽量部署时不依赖镜像变更。

这些方法目前看来已经覆盖了大多数主流场景，不管是 Linux 还是 Windows，物理机还是虚拟机，整盘备份还是分区备份。做镜像这件事，刚接触时觉得很高深，做多了就会明白它本质上就是“完整复制 + 环境适配”两件事。把这两件事拆开，一步步来，最终一定能得到一个干净、稳定、可直接使用的系统镜像。