Your Proxmox backup job probably skips the guests you built after you made it. Here's the 3-2-1 setup that doesn't

查看原文 / View Original 编辑 / Edit

本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

I ran a Proxmox homelab for years with a backup job that reported success every night. It had been created for “selected VMs” and every guest I built after that was simply not in the list. The job was fine. It was protecting the wrong things. This is the setup I run now for a home Proxmox cluster with OPNsense and Home Assistant on it. Nothing exotic: vzdump, Proxmox Backup Server, rclone, and a small amount of discipline around proving it works.

多年来，我一直运行着一个 Proxmox 家庭实验室，其备份任务每晚都显示成功。该任务最初是为“选定的虚拟机”创建的，因此之后我构建的每个客户机都不在列表中。任务本身没问题，但它保护的对象错了。这是我现在为运行 OPNsense 和 Home Assistant 的家庭 Proxmox 集群所采用的设置。没有什么花哨的东西：vzdump、Proxmox Backup Server、rclone，以及一点点确保其正常工作的纪律。

  1. The job covers everything by default Datacenter → Backup → Add. The settings that matter: Selection mode: All, with your scratch guests under Exclude. New guests are protected the day they are created. Mode: Snapshot, Compression: ZSTD, nightly at a quiet hour. Retention: use storage defaults, so the numbers live in one place. Notification mode: Notification system (not legacy email), so matchers can route failures to your phone. Notes template: {{guestname}} on {{node}}, so the backup list is readable at 2 AM.

  2. 该任务默认覆盖所有内容：数据中心 → 备份 → 添加。关键设置包括：选择模式：全部，并将临时客户机放在“排除”列表中。这样，新客户机在创建当天就会受到保护。模式：快照，压缩：ZSTD，每晚在空闲时间运行。保留策略：使用存储默认值，以便将数值统一管理。通知模式：通知系统（而非旧版电子邮件），以便匹配器将故障信息发送到你的手机。备注模板：{{guestname}} on {{node}}，这样在凌晨 2 点查看备份列表时也能一目了然。

The same thing on the command line, which is what the GUI writes into /etc/pve/jobs.cfg: vzdump —all 1 —exclude 900,901 —mode snapshot —compress zstd \ —storage nas-backup —notes-template ‘{{guestname}} on {{node}}’ \ —notification-mode notification-system Put the archives on something that is not the host’s own disk. An NFS export on the NAS is the simplest: pvesm add nfs nas-backup —server 192.168.10.40 —export /volume1/proxmox \ —content backup —options vers=4.1 pvesm set nas-backup \ —prune-backups keep-last=2,keep-daily=7,keep-weekly=4,keep-monthly=3

命令行下的操作与此相同，这也是 GUI 写入 /etc/pve/jobs.cfg 的内容：vzdump —all 1 —exclude 900,901 —mode snapshot —compress zstd \ —storage nas-backup —notes-template ‘{{guestname}} on {{node}}’ \ —notification-mode notification-system。将归档文件存放在非宿主机自身的磁盘上。在 NAS 上进行 NFS 导出是最简单的做法：pvesm add nfs nas-backup —server 192.168.10.40 —export /volume1/proxmox \ —content backup —options vers=4.1 pvesm set nas-backup \ —prune-backups keep-last=2,keep-daily=7,keep-weekly=4,keep-monthly=3。

Install the QEMU guest agent in every VM (apt install qemu-guest-agent, enable it in the VM’s Options). With it, snapshot mode asks the guest to flush its filesystems first, which is the difference between a consistent backup and one that needs fsck on restore. Add —bwlimit 50000 if the nightly run makes anything laggy. It did for me.

在每个虚拟机中安装 QEMU guest agent（apt install qemu-guest-agent，并在虚拟机的选项中启用它）。有了它，快照模式会要求客户机先刷新其文件系统，这决定了备份是保持一致的，还是在恢复时需要进行 fsck 检查。如果每晚的运行导致系统卡顿，请添加 —bwlimit 50000。我就遇到了这种情况。

  1. Retention: keep-daily=7 does not mean seven days keep-daily=7 means “keep the last backup from each of the last seven days that have a backup”. If the job failed for a month and then ran once, that single run satisfies keep-daily, keep-weekly and keep-monthly at the same time, and pruning deletes the older ones. The rules never promise coverage of time. So the weekly and monthly buckets matter more than the daily ones, and keep-last is the safety margin for “I just took a backup before an upgrade”.

  2. 保留策略：keep-daily=7 并不意味着保留七天。keep-daily=7 的意思是“保留最近七天内每一天最后一次的备份”。如果任务失败了一个月然后运行了一次，那么这一次运行会同时满足 keep-daily、keep-weekly 和 keep-monthly，而清理程序会删除更旧的备份。这些规则并不保证时间覆盖率。因此，周备份和月备份比日备份更重要，而 keep-last 是“我在升级前刚做了一个备份”的安全边际。

What I use: Guest type keep-last daily weekly monthly Databases, Home Assistant 2 14 8 6 Ordinary services 2 7 4 3 OPNsense (barely changes) 2 0 8 6 Ten minutes with the Prune Simulator in the PBS docs fixed a misunderstanding I had carried for years. Before a risky change, take a manual backup and mark it Protected (the shield icon). It survives every prune until you clear the flag.

我使用的配置：客户机类型 keep-last 日备份 周备份 月备份；数据库、Home Assistant 2 14 8 6；普通服务 2 7 4 3；OPNsense（几乎不变） 2 0 8 6。花十分钟使用 PBS 文档中的“清理模拟器”（Prune Simulator），纠正了我多年来的一个误解。在进行风险操作前，请手动备份并将其标记为“受保护”（盾牌图标）。在清除该标志之前，它将免受任何清理操作的影响。

  1. Proxmox Backup Server, with the key saved somewhere else vzdump copies the whole guest every night. PBS splits every disk into chunks, stores each unique chunk once, and after the first run only ships what changed. Thirty nightly backups of a 32 GB Home Assistant VM take a little more space than one. Put PBS on its own box, or at least its own disks.

  2. Proxmox Backup Server，并将密钥保存在其他地方。vzdump 每晚复制整个客户机。PBS 将每个磁盘拆分为数据块，仅存储每个唯一的数据块一次，并且在首次运行后仅传输更改的部分。一个 32 GB 的 Home Assistant 虚拟机，三十次每晚备份所占用的空间仅比一次备份多一点点。请将 PBS 放在独立的机器上，或者至少使用独立的磁盘。

Then: # on PBS proxmox-backup-manager datastore create backups /mnt/datastore/backups proxmox-backup-manager user create backup@pbs proxmox-backup-manager acl update /datastore/backups DatastoreBackup \ —auth-id backup@pbs proxmox-backup-manager cert info | grep Fingerprint # on the Proxmox node pvesm add pbs pbs01 —server 192.168.10.30 —datastore backups \ —username backup@pbs —password ’…’ —fingerprint ‘aa:bb:…’ pvesm set pbs01 —encryption-key autogen

然后：# 在 PBS 上 proxmox-backup-manager datastore create backups /mnt/datastore/backups proxmox-backup-manager user create backup@pbs proxmox-backup-manager acl update /datastore/backups DatastoreBackup \ —auth-id backup@pbs proxmox-backup-manager cert info | grep Fingerprint # 在 Proxmox 节点上 pvesm add pbs pbs01 —server 192.168.10.30 —datastore backups \ —username backup@pbs —password ’…’ —fingerprint ‘aa:bb:…’ pvesm set pbs01 —encryption-key autogen。

That last line encrypts every chunk on the client before it leaves the node, and writes the key to /etc/pve/priv/storage/pbs01.enc. Copy that key somewhere that is not this cluster (password manager, printed QR). Without it, every encrypted backup is unrecoverable. With it, you can restore onto a brand-new Proxmox install. It is the one mistake in all of this with no undo.

最后一行代码会在数据离开节点前在客户端加密每个数据块，并将密钥写入 /etc/pve/priv/storage/pbs01.enc。请将该密钥复制到此集群之外的地方（密码管理器、打印的二维码等）。没有它，所有加密备份都将无法恢复。有了它，你可以在全新的 Proxmox 安装上进行恢复。这是整个过程中唯一无法撤销的错误。

On the PBS side, schedule three jobs under the datastore: a prune job with the same keep-* numbers, daily garbage collection (pruning only unlinks; GC frees chunks, after a 24-hour grace period), and a weekly verify job with “skip verified” on and “re-verify after” set to 30 days.

在 PBS 端，在数据存储下安排三个任务：使用相同 keep-* 数值的清理任务、每日垃圾回收（清理仅取消链接；垃圾回收在 24 小时宽限期后释放数据块），以及每周一次的验证任务，开启“跳过已验证”并将“重新验证周期”设置为 30 天。

  1. Off-site: rclone with a crypt layer Everything above is still in one house. The cheapest third copy I know of is an encrypted rclone sync to object storage. Two remotes: the raw bucket, and a crypt remote on top so the provider only ever sees encrypted names and content.

  2. 异地备份：带有加密层的 rclone。以上所有内容仍位于同一处。我所知道的最便宜的第三份副本是使用 rclone 将加密数据同步到对象存储。设置两个远程端：原始存储桶，以及在其之上建立的加密远程端，这样服务提供商只能看到加密的文件名和内容。

rclone config # n) name: b2raw, type: b2, paste the key ID and key (scoped to one bucket) # n) name: b2, type: crypt, remote: b2raw:homelab-backups, two passwords chmod 600 ~/.config/rclone/rclone.conf rclone sync /mnt/backups/dump b2:dump \ —transfers 4 —bwlimit “08:00,2M 23:00,off” —fast-list \ —log-file /var/log/rclone-b2.log —log-level INFO

rclone config # n) name: b2raw, type: b2, 粘贴密钥 ID 和密钥（限定于一个存储桶） # n) name: b2, type: crypt, remote: b2raw:homelab-backups, 两个密码 chmod 600 ~/.config/rclone/rclone.conf rclone sync /mnt/backups/dump b2:dump \ —transfers 4 —bwlimit “08:00,2M 23:00,off” —fast-list \ —log-file /var/log/rclone-b2.log —log-level INFO。

sync mirrors deletions, which is right for a dump directory that prunes itself. Set a lifecycle rule on the bucket so hidden old versions expire after ~30 days, and use rclone copy (never deletes) for anything irreplaceable. rclone check b2:dump /mnt/backups/dump compares without transferring; run it monthly. The crypt passwords go in the same place as the PBS key. If a friend runs PBS too, a push sync job over Tailscale is even better: proxmox-backup-manager sync-job create … —sync-direction push. Client-side encryption means neither of you can read the other’s data.

sync 会镜像删除操作，这对于会自动清理的转储目录来说是正确的。在存储桶上设置生命周期规则，使隐藏的旧版本在约 30 天后过期，并对不可替代的内容使用 rclone copy（从不删除）。rclone check b2:dump /mnt/backups/dump 可在不传输的情况下进行比较；每月运行一次。加密密码应存放在与 PBS 密钥相同的地方。如果朋友也运行 PBS，通过 Tailscale 进行推送同步任务会更好：proxmox-backup-manager sync-job create … —sync-direction push。客户端加密意味着你们双方都无法读取对方的数据。

  1. The alert you actually need is “nothing succeeded recently” A job that never runs never fails. The off-site sync that stopped in February will not send a single error until the day you need it. Alerting on failure is not enough; you need a dead-man switch that expects a ping. vzdump has hook scripts for exactly this. In /etc/vzdump.conf: script: /usr/local/bin/vzdump-hook.sh #!/bin/bash # vzdump calls this with the phase as $1 URL=https://hc-ping.com/your-uuid-here # healthchecks.io, or an Uptime Kuma push monitor case “$1” in

  2. 你真正需要的警报是“最近没有任何任务成功”。从不运行的任务永远不会失败。二月份停止的异地同步任务，直到你需要它那天之前都不会发送任何错误信息。仅在失败时报警是不够的；你需要一个等待心跳信号的“死人开关”（dead-man switch）。vzdump 正好有用于此目的的钩子脚本。在 /etc/vzdump.conf 中：script: /usr/local/bin/vzdump-hook.sh #!/bin/bash # vzdump 以阶段作为 $1 参数调用此脚本 URL=https://hc-ping.com/your-uuid-here # healthchecks.io 或 Uptime Kuma 推送监控 case “$1” in

← 返回新闻列表 / Back to news list