VM 备份 / 迁移 / Cloud-Init

这篇对应脚本里的"虚拟机高级运维工具箱"，覆盖备份恢复、模板克隆、Cloud-Init、磁盘快照网络、集群内迁移。

备份与恢复

优先用脚本的 VM 备份与恢复 菜单，它是对官方 vzdump / qmrestore 的交互式封装：

三条经验：日常备份用 snapshot 模式；VM 挂了大盘或者对 IO 敏感的，动手前先确认目标存储的空间和吞吐；恢复成新 VM 时保留 --unique 1，否则网络标识会撞车。

导出的配置文件本质上是带元信息头的 qm config 快照。导入时脚本不直接覆盖 /etc/pve/qemu-server/<VMID>.conf，而是先 qm create 建空白 VM，再用 qm set 逐项回放。

绕这一圈有三个好处：不动集群配置文件、符合 PVE 9 集群环境下的操作习惯、出错时能精确定位到是哪一项失败的。

两种导入模式：

云镜像模板的推荐流程：

有三条约束要记住：cicustom 依赖支持 snippets 内容类型的存储；链接克隆只建议对模板用，且通常要求共享或可克隆的存储；Windows 场景一般需要 Cloudbase-Init，脚本目前主打的是 Linux Cloud-Init 流程。

类别	能做的操作
磁盘	在线/离线扩容、添加磁盘、删除磁盘插槽、迁移到其他存储
快照	批量创建、查看指定 VM 的快照、删除、回滚
启动	开机自启 `onboot`、启动顺序 `boot order=...`、启动延迟 `startup=...`
网络	网卡增删、bridge 与 VLAN 修改

脚本封装的是集群内 qm migrate，不是跨集群的远程迁移。

迁移前确认四件事：目标节点在线、目标存储存在或能用 --targetstorage 正确映射、要不要带本地磁盘一起走、VM 有没有 PCI / GPU / NVMe 直通这类硬件绑定。

为什么没做 remote-migrate： 在当前 PVE 9 的官方文档语境里，qm remote-migrate 还不适合当脚本的默认自动化入口。先把集群内迁移和备份恢复型迁移做扎实，比急着上远程迁移更稳妥。

模板化交付：cloud image → Cloud-Init → 模板 → 链接克隆

保险型迁移：vzdump 备份 → qmrestore 到新 VMID → 验证业务 → 切换流量

日常运维：快照 → 改磁盘/网络/启动策略 → 验证 → 不对就回滚

在备份恢复、配置导入、模板克隆、Cloud-Init、磁盘、快照、迁移这些环节动错了对象，第一反应不该是继续修正，而是停止写入。