外观
快照或备份失败
适用范围
打快照、删快照或跑备份任务时报错或卡住,虚拟机本身能正常开关机。
不适用于虚拟机启动本身失败(见虚拟机开不了机),也不适用于恢复(restore)过程的问题——恢复相关见恢复演练。
开始排查前
先看清楚失败的是哪一类操作,原因方向完全不同:
- 打快照失败
- 删快照失败(通常表现为卡很久或报错)
- 备份任务(vzdump)失败
- 备份任务里包含快照阶段失败
快照卡在删除中,不要强行中断
快照删除(尤其是 ZFS 或有多层快照链的情况)可能需要合并数据,耗时较久属于正常现象。中途强行重启宿主机或者手动改配置文件,可能让快照链处于不一致状态,导致虚拟机磁盘数据损坏。先确认它是真的卡死还是只是慢,见下面的排查步骤。
排查步骤
第一步:确认这个存储本身支不支持快照
不是所有存储都能做快照,这是最容易被忽略的前提:
| 存储类型 | 支持快照 |
|---|---|
| qcow2(Directory / NFS 上的文件) | 是 |
| raw(Directory / NFS 上的文件) | 否,raw 本身没有快照能力 |
| LVM-Thin | 是 |
| 普通 LVM(非 thin,含 iSCSI/FC 上的 LVM) | 传统上否;PVE 9.0 起对这类共享存储引入了基于卷链 (volume chain) 的快照支持,仍是技术预览 |
| ZFS | 是 |
| Ceph RBD | 是 |
PVE 9 的厚置备 LVM 共享存储快照还是技术预览
如果是 PVE 9.x 环境,在 iSCSI/FC 接的共享 LVM 存储上看到快照选项可用,这是新加入的能力,通过给每个快照单独创建逻辑卷、叠加 qcow2 覆盖层实现,性能开销比原生块存储快照明显更高,且仍标注为技术预览。生产环境谨慎评估,具体行为以你实际测试和官方发布说明为准。
sh
pvesm status
qm config <vmid> | grep -E '^(scsi|sata|virtio|ide)[0-9]'对照磁盘所在的存储类型和格式。报错里提到「不支持快照」或者 Take Snapshot 按钮本身是灰的,说明就是这个原因,需要先按存储模型把磁盘迁移到支持快照的存储上,而不是继续排查。
第二步:包含内存(RAM)的快照失败
勾了 Include RAM 的快照,除了磁盘空间还要占用相当于虚拟机内存大小的存储空间来保存内存状态:
sh
# 目标存储的可用空间
pvesm status内存分配的虚拟机(比如给了 16G 内存)打带内存的快照,至少要多出 16G 左右的可用空间。空间不够会直接失败。不需要保留运行现场的话,不勾 RAM 能规避这个限制。
第三步:备份任务失败,先看是不是一致性问题
Snapshot 模式的备份依赖 QEMU Guest Agent 来冻结文件系统再拍快照:
sh
# 查看任务日志,正常情况下能看到 fs-freeze 相关的行
cat /var/log/pve/tasks/active日志里如果能看到类似 issuing guest-agent 'fs-freeze' command 但之后没有对应的 fs-thaw 或者卡在这一步,说明客户机内部的冻结没有正常完成——可能是客户机负载太高、文件系统卡住,或者 agent 版本太旧。检查客户机内部:
sh
# 在客户机内部执行(Linux)
systemctl status qemu-guest-agent没装 agent 时,PVE 会退化成不冻结直接拍照(等同于虚拟机突然断电的状态),这不算"失败",但恢复出来的数据一致性没有保证,属于备份任务里说明过的已知限制。
第四步:空间不足导致的失败
sh
df -h # 目录存储 / 备份目标
lvs -a 2>/dev/null # LVM-Thin 的 Data% 和 Meta%
zpool list 2>/dev/null- 备份目标空间不够:清理旧备份或扩容,见备份任务的保留策略部分。
- 源存储(LVM-Thin)空间不够:打快照本身也会占用空间,池快满时打快照可能直接失败,见 local-lvm 满了。
第五步:报错和锁有关
VM is locked (snapshot) 或者类似提示,说明上一次快照/备份操作的锁没有被正常清除。先确认对应任务真的已经结束,再参考虚拟机被锁定处理,不要直接解锁。
第六步:快照链本身出了问题
长期不清理的快照会形成很长的链条,个别情况下(尤其是掉电、存储抖动之后)快照的元数据可能和实际数据对不上,表现为删除快照报错、或者备份时报磁盘相关的错误。
sh
# ZFS:确认池本身状态正常,这是快照能否正常工作的前提
zpool status -v池状态不是 ONLINE 时,先处理底层存储问题(见 ZFS 池降级),再回来处理快照。
快照链损坏时不要凭感觉手动删数据文件
直接在存储后端手动删除快照相关的文件或 LVM 卷,可能让整条快照链(包括之后的所有快照,甚至当前磁盘状态)一起损坏且不可恢复。这类操作应先在官方论坛确认具体存储类型的正确处理方式,或者从确认可用的备份恢复到新的 VM ID,而不是在原数据上试错。
确认恢复
- 重新执行一次同样的快照或备份任务,能正常完成。
- 快照相关:
qm listsnapshot <vmid>输出符合预期,没有多余或残缺的记录。 - 备份相关:跑一次恢复演练,确认这份备份真的能恢复出可用的虚拟机,而不是只看任务显示成功。
- 任务日志里不再出现异常的 freeze/thaw 或存储报错。
仍未解决
准备好按如何有效求助整理:
sh
pveversion -v
qm config <vmid>加上失败任务的完整日志、磁盘所在存储的类型和状态(pvesm status、必要时 zpool status -v)。