配置备份任务与保留策略

PVE 的备份叫 vzdump，它把一台客户机打包成一个文件。这篇把备份任务配起来，并解释那几个容易选错的选项。

第一步：确定备份存到哪

不要备份到 local

默认的 local 存储在系统盘上。把备份放在那里，系统盘坏了备份和配置一起没，等于白做。

备份的第一要求是和源数据不在同一个故障域。

按推荐程度排序：

目标	优点	代价
Proxmox Backup Server	增量、去重、校验，空间效率最高	要额外一台机器（或虚拟机 + 独立存储）
另一台机器的 NFS 共享	简单，PVE 原生支持	全量备份，占空间
本机的独立数据盘	最省事	同一台机器，只防盘坏不防机器坏
外接 USB 硬盘	便宜，可离线保存	要手动插拔，容易忘

挂载 NFS 存储：数据中心 → 存储 → 添加 → NFS，填服务器地址和导出路径，内容类型勾 VZDump backup file。

至少做到「不在同一块盘」，目标是「不在同一台机器」

条件有限时，先做到备份在另一块物理盘上——这已经能挡住最常见的单盘故障。但要清楚这只是过渡方案，真正的目标是异机甚至异地。

第二步：理解三种备份模式

这是最需要想清楚的选项。

模式	客户机状态	数据一致性	停机时间
Snapshot	一直运行	取决于有没有 guest agent	几乎没有
Suspend	暂停 → 备份 → 恢复	较好	备份全程暂停
Stop	关机 → 备份 → 开机	最好	备份全程关机

Snapshot 模式的一致性取决于 guest agent

没装 QEMU Guest Agent 时，snapshot 模式相当于在运行中直接拍一张磁盘照片——等同于客户机突然断电。恢复出来的系统会像经历了一次非正常关机，文件系统可能需要修复，正在写入的数据库可能损坏。

装了 agent 时，PVE 会先让客户机把缓存刷盘并冻结文件系统，拍完再解冻。这才是 snapshot 模式该有的样子。

结论：用 snapshot 模式的前提是客户机装了 guest agent。 见 VirtIO 驱动与 QEMU Guest Agent。

实践建议：

• 绝大多数客户机：Snapshot + guest agent。
• 跑数据库且要求严格一致：Stop 模式，或者在客户机内部做应用级备份（mysqldump 之类）再做 vzdump。
• 不重要、可以随时停的：Stop 模式最省心。

第三步：创建备份任务

数据中心 → 备份 → 添加：

字段	建议
Node	单机选你的节点
Storage	第一步准备的备份存储
Schedule	见下文
Selection mode	All（全选）或手动勾选
Send email to	填你的邮箱
Email notification	见下文
Compression	ZSTD（快且压缩率好）
Mode	见上一节

Schedule 怎么填

用的是类似 systemd timer 的语法：

02:30                    每天 02:30
mon..fri 02:30           工作日 02:30
sat 03:00                每周六 03:00
*/6:00                   每 6 小时

别让所有备份挤在同一时刻

多个备份任务同时跑会让 IO 打满，客户机卡顿。错开时间，或者用一个任务备份多台。

Selection mode 选 All 的好处

选 All 表示「备份所有客户机」。以后新建的客户机会自动被纳入备份。

手动勾选的问题是：三个月后你建了一台新的重要虚拟机，忘了加进备份任务，直到出事才发现。

想排除某几台，用 All 配合 Exclude 列表，而不是用手动勾选。

Email notification

• Always：每次备份都发邮件。开始时建议用这个，能确认备份真的在跑。
• On failure only：只在失败时发。前提是你确认邮件真的能发出去，见第一次登录。

「没收到失败邮件」不等于「备份成功」

如果邮件根本发不出去，你会永远收不到失败通知，然后以为一切正常。先验证邮件通道可用，再改成 On failure only。

第四步：配置保留策略

在备份任务的 Retention 标签页，或者在存储的配置里。

PVE 用的是分级保留：

选项	含义
Keep Last	保留最近 N 份，不管时间
Keep Daily	保留最近 N 天，每天一份
Keep Weekly	保留最近 N 周，每周一份
Keep Monthly	保留最近 N 月，每月一份
Keep Yearly	保留最近 N 年，每年一份

一个适合家庭/小团队的起点：

Keep Daily:   7
Keep Weekly:  4
Keep Monthly: 3

这样你有：最近一周每天一份、最近一个月每周一份、最近三个月每月一份。总共约 14 份。

为什么要保留这么久

因为不是所有问题都能立刻发现。数据被误删、配置被改坏、文件被静默损坏，可能几周后才察觉。只保留最近 3 天的话，那时候已经来不及了。

勒索软件尤其如此——它可能潜伏一段时间再发作。

先算空间够不够

全量备份的存储占用 = 单份大小 × 保留份数。四台各 20 GB 的虚拟机、保留 14 份，就是 1 TB 出头（ZSTD 压缩后会少一些，但要按最坏情况算）。

空间不够时的正确做法是用 PBS 做增量去重，或者减少保留份数，不是把备份关掉。

第五步：跑一次并确认

不要等定时任务。选中任务点 Run now。

看任务日志（数据中心 → 任务 或点任务的 Logs）：

INFO: Starting Backup of VM 100 (qemu)
INFO: creating vzdump archive '/mnt/backup/dump/vzdump-qemu-100-....vma.zst'
INFO: Backup job finished successfully

关键是最后那行 finished successfully。

日志里出现 "guest-fsfreeze" 是好事

snapshot 模式下，日志里能看到类似 issuing guest-agent 'fs-freeze' command 的行，说明 agent 在工作、备份拿到了一致性冻结。看不到这行，回头检查 agent。

命令行

# 手动备份一台
vzdump <vmid> --storage <存储名> --mode snapshot --compress zstd

# 备份所有
vzdump --all --storage <存储名> --mode snapshot

# 看备份列表
pvesm list <存储名> --content backup

备份任务的定义在 /etc/pve/jobs.cfg。

别忘了宿主机自己

vzdump 备份的是客户机。宿主机的配置（存储定义、网络、用户、防火墙规则、客户机配置文件）在 /etc/pve 里，不在任何客户机备份中。

宿主机重装后，如果 /etc/pve 没备份，所有客户机定义都要重建（虽然磁盘还在）。

一个简单的做法是定期归档它：

tar czf /mnt/backup/pve-etc-$(date +%F).tar.gz /etc/pve /etc/network/interfaces /etc/hosts

这个归档里有敏感信息

/etc/pve 包含集群证书、用户配置和 API Token 的相关数据。这个文件要和你的其他敏感备份同等对待，不要随手扔在共享目录里。

完整的宿主机备份方案会在本章后续文章展开。

检查结果

1. 数据中心 → 备份 里有任务，且 Schedule 正确。
2. 手动 Run now 一次，任务日志 finished successfully。
3. pvesm list <备份存储> --content backup 能看到备份文件。
4. 备份存储所在的物理位置，不是客户机磁盘所在的那块盘。
5. 收到了备份完成的邮件（或者你已经知道邮件发不出去，并打算解决）。

五项都过之后，立刻去做恢复演练。在恢复成功之前，你还不能说备份做好了。

延伸阅读

• 恢复演练
• VirtIO 驱动与 QEMU Guest Agent
• 官方文档：Backup and Restore