PVE 定时备份体系：vzdump 落 NAS + 宿主机配置打包
摘要
虚机和容器越跑越多，备份不能靠"想起来再手动备"。这篇记录 PVE 的定时备份体系：vzdump 定时备份虚机/容器到 NAS（小备份每 3 天、大的每月），宿主机配置每周打包，保留策略用 --prune-backups keep-last=N。重点写了备份策略总表（3-2-1 原则怎么落地）、vzdump 保留参数的版本差异（PVE 9 没有 --maxfiles）、以及"备份时间表要全家统一规划"这个容易忽略的点。
目录
- 一、备份策略总表：3-2-1 原则的落地
- 二、存储：nas-pve-backup 挂哪
- 三、vzdump 定时任务：大小备份分开
- 四、vzdump 的保留参数：--prune-backups keep-last=N
- 五、宿主机配置备份：每周打包
- 六、备份时间表：全家统一规划
- 七、验证：备份≠备了，要能恢复
- 八、踩坑记录
- 九、总结
一、备份策略总表：3-2-1 原则的落地
3-2-1 备份原则：3 份数据、2 种介质、1 份异地。在这套家庭数据中心里，它是这么落地的：
| 数据 | 第 1 份（在线） | 第 2 份（NAS） | 第 3 份（异地） |
|---|---|---|---|
| PVE 虚机/容器 | 运行中 | vzdump 定时备到 NAS | Google Drive 异地备份（规划中） |
| PVE 宿主机配置 | /etc/pve 等 | 每周打包到 NAS | 同上 |
| vaultwarden | CT700 运行中 | 每日 03:30 备到 NAS | 同上 |
| NAS 办公文件 | NAS 在线 | ——（本身就是第 2 份） | Google Drive 异地备份 |
PVE 备份体系是第 2 份的核心：虚机/容器、宿主机配置，定时落到 NAS。异地（Google Drive）是第 3 份，见《Google Drive 异地备份》系列（规划中）。3-2-1 不是口号，是每类数据都能指着表格说出"我的三份在哪"。
二、存储：nas-pve-backup 挂哪
PVE 新增 dir 类型存储 nas-pve-backup，指向 NAS 上 //192.168.0.106/docker 共享下的 PVEBackup/ 目录（85G 可用）。vzdump 的备份文件直接写这里，不经过 PVE 本地磁盘中转。
选 //192.168.0.106/docker 这个共享是权衡过的：它是 NAS 上空间最宽裕的共享之一，PVEBackup 独立子目录，和其他用途隔离。备份存储和业务存储分开，备份把空间吃满了不影响业务。
三、vzdump 定时任务：大小备份分开
备份频率按"数据变化速度"和"体积"分两档：
| 档 | 对象 | 频率 | 保留 | 时间 |
|---|---|---|---|---|
| 小备份 | VM102、CT700、CT701、CT702 | 每 3 天 | 3 份 | 凌晨 2 点 |
| 大备份 | VM1002（办公虚机，体积大） | 每月 1 号 | 2 份 | 凌晨 3 点 |
# /etc/cron.d/vzdump（示意）
# 小备份：每 3 天凌晨 2 点
0 2 */3 * * root vzdump 102 700 701 702 --storage nas-pve-backup --prune-backups keep-last=3
# 大备份：每月 1 号凌晨 3 点
0 3 1 * * root vzdump 1002 --storage nas-pve-backup --prune-backups keep-last=2
VM1002 单独成档的原因：办公虚机，60G 磁盘，备份文件大，每天备不现实。CT700/701/702 是轻量容器，3 天一次无压力。频率不是拍脑袋，是按"丢几天数据能接受"和"备份窗口够不够"算出来的。
四、vzdump 的保留参数：--prune-backups keep-last=N
PVE 9 的 vzdump，保留策略参数是 --prune-backups keep-last=N，没有 --maxfiles。旧教程里常见的 --maxfiles 在 PVE 9 上会报错，这是版本差异，抄旧教程前先看版本。
# 保留最近 3 份，旧的自动删
vzdump 102 --prune-backups keep-last=3
keep-last=N 的语义：每次备份完成后，自动清理，只保留最近的 N 份。不用自己写 find -mtime 清理，vzdump 原生支持。备份脚本里别再手写清理逻辑，重复了还容易出错。
五、宿主机配置备份：每周打包
虚机备了，宿主机本身也要备。PVE 宿主机的"配置"散在几个地方：
# /root/pve-host-backup.sh（核心思路）
# 每周日 02:30 打包，保留 4 份
tar -czf /mnt/nas/PVEBackup/host/pve-host-$(date +%F).tar.gz \
/etc/pve \ # 集群配置、虚机/容器配置
/etc/network/interfaces \ # 网络配置
/etc/fstab \ # 挂载
/etc/cron.d/ \ # 定时任务
/root/ # 管理脚本（pve-mgmt、签发工具等）
/etc/pve 是最重要的：所有虚机/容器的配置文件都在里面。/root/ 下的管理脚本（pve-mgmt 工具链、gl 菜单、签发器）是多年积累的运维资产，一并打包。每周日 02:30，保留 4 份。
宿主机配置备份的恢复场景：PVE 宿主机系统盘挂了，重装 PVE 后，把 /etc/pve 和网络配置恢复回去，虚机/容器的定义就回来了，再从 vzdump 备份恢复数据。两层备份（配置 + 数据）配合，才是完整的灾难恢复。
六、备份时间表：全家统一规划
家里现在的定时任务不少，备份时间必须统一规划，避免 IO 打架：
| 时间 | 任务 |
|---|---|
| 02:00 | PVE 小备份（每 3 天） |
| 02:30 | PVE 宿主机配置打包（每周日） |
| 03:00 | PVE 大备份（每月 1 号） |
| 03:30 | vaultwarden 备份（每日） |
| 04:00 | Google Drive 异地备份（每日，规划中） |
原则：大 IO 任务错开半小时以上；都在凌晨，用户无感知的时段。新加定时备份任务时，先查这张表，别硬挤。时间表记在 NAS 运维日志里，改时间先更新表。
七、验证：备份≠备了，要能恢复
2026-10-01 上线当天就做了验证：手动跑一次 CT700 的 vzdump 备份（571M 落 NAS 成功），宿主机打包脚本跑一次成功。但这只是"备下来了"，真正的验证是恢复演练：
| 验证项 | 状态 |
|---|---|
| vzdump 备份能生成 | 已验证（CT700，571M） |
| 备份文件在 NAS 上 | 已验证 |
| 宿主机打包脚本 | 已验证 |
| 从备份恢复虚机 | 待办：找机会演练一次 |
| 从备份恢复宿主机配置 | 待办 |
没做过恢复演练的备份等于没备份，这句话在这篇里再说一遍。vzdump 的恢复是 qmrestore/pct restore，找个不重要的容器演练一次，流程走通才算数。演练记在待办里，定期做。
八、踩坑记录
坑 1：PVE 9 没有 --maxfiles
旧教程的 --maxfiles 在 PVE 9 上无效，正确参数是 --prune-backups keep-last=N。抄教程前先确认 PVE 版本，pveversion 看一眼只要 3 秒。
坑 2：备份目标存储要在 PVE 里先加好
vzdump 的 --storage 指定的存储，必须先在 PVE 的"数据中心 - 存储"里添加（dir 类型，指向 NAS 挂载）。没加就跑 vzdump，报错信息不直观，容易误判为权限问题。
坑 3：NAS 未就绪时备份会失败
PVE 重启后，如果 NAS 挂载还没就绪（网络/认证慢），vzdump 会失败。备份脚本里加个前置检查：NAS 挂载点可写才继续，否则记日志退出。别让失败的备份静默过去。
恢复演练实操：找个不重要的容器练手
恢复演练别拿生产虚机练，找个不重要的 LXC 容器（比如测试容器），走一遍：
# 1. 记下容器当前状态（快照也行，双保险）
# 2. 删容器（模拟灾难）
pct destroy <ctid>
# 3. 从 vzdump 备份恢复
pct restore <ctid> /mnt/pve/nas-pve-backup/dump/vzdump-lxc-<ctid>-xxx.tar.zst \
--storage local-lvm
# 4. 起容器，验证业务
pct start <ctid>
# 5. 进业务确认：Web 能打开、数据在
演练完记下来：恢复用了多久、哪一步卡了、文档要不要改。演练的目标不是"证明备份能用"，是"把恢复流程练成肌肉记忆"。真灾难时，没人有时间翻文档。
异地备份衔接：NAS→Google Drive
NAS 是第 2 份，异地是第 3 份。PVEBackup 落到 NAS 后，rclone 定时同步到 Google Drive（见异地备份规划）：
- 同步频率：每日一次，和本地备份错开时间；
- 只同步新增/变化的（rclone sync），不每次全量；
- 异地那份是"火灾盗窃"级的保险，平时不用，关键时救命。
3-2-1 的"1"最容易被省略（"NAS 都有了还异地干嘛"），但 NAS 和 PVE 在同一个屋子里，火灾、水灾、入室盗窃是一锅端的。异地备份是最后的底线，宁可慢，不可无。
备份的心理学：为什么人总是不备份
备份的道理人人都懂，但"没备份就丢数据"的故事天天上演。为什么？因为备份的收益是"未来的、概率的"，成本是"现在的、确定的"。人脑天生短视：现在花 10 分钟配备份，收益是"未来某天可能不丢数据"，这笔账在直觉上永远算不过来。所以备份不能靠"自觉"，要靠"系统"。
系统一：自动化。 vzdump 定时任务、宿主机每周打包、vaultwarden 每日 03:30，全是 cron/systemd 在跑，不用人想起来。自动化的本质，是把"未来的收益"变成"现在的零成本"——配好一次，以后每次备份的成本都是零。零成本的事，不需要意志力。
系统二：可见性。 备份跑完，记个日志；日志定期看一眼，确认"昨天备了、多大"。看不见的备份等于没备份——cron 挂了、NAS 满了、权限变了，备份静默失败，半年后才发现。Uptime Kuma 可以加个"备份文件新鲜度"监控：NAS 上的最新备份超过 2 天没更新就告警。备份的可见性，和监控一个道理：没告警的异常，等于没发现。
系统三：演练。 前面说了，恢复演练是肌肉记忆。演练还有个心理作用：让你"相信"备份是真的。没演练过的备份，心里永远有个问号："这玩意儿真能恢复吗？"问号不消除，备份的"安心感"就是假的。演练一次，问号变句号。
三层系统下来，备份从"道理"变成"习惯"，从"习惯"变成"系统"。系统不需要意志力，系统只需要维护。这也是这套家庭数据中心的通用哲学：凡是靠"记住"的事，都改成靠"系统"。备份如是，证书续期如是，隧道看门狗如是。
备份的 3-2-1 在家庭场景的变体
3-2-1 原则（3 份数据、2 种介质、1 份异地）是企业级的，家庭场景要变通。企业的"2 种介质"是磁带+磁盘，家庭的"2 种介质"是"NAS 硬盘 + 移动硬盘/云"。教条地抄 3-2-1，家庭玩不起；理解它的精神，变体完全够用。
变体一：介质可以是"逻辑隔离"。PVE 备份在 NAS 上，NAS 和 PVE 是两台设备、两个系统，一个挂了另一个还在。这就是"2 种介质"的家庭版：物理隔离代替介质隔离。 perfection 是磁带机，够用是"别放同一台机器"。
变体二：异地可以是"云"。Google Drive 异地备份，就是家庭的"1 份异地"。不用买磁带、不用租机柜，一个 rclone 命令，数据就在另一个大洲了。云的缺点是"数据在别人手里"，对策是加密（rclone crypt），敏感数据先加密再上传。异地的意义是"房子没了数据还在"，加密的意义是"数据在别人手里也看不懂"。
变体三：3 份可以是"2+1"。在线一份、NAS 一份，这是"2"；异地那份，可以频率低一点（每周一次），因为它是"救命"不是"日常"。日常恢复（误删文件）用 NAS 的快照和备份，异地是"房子烧了"才用的。分级，才能坚持——每天全量异地，带宽和钱包都扛不住。
3-2-1 的精神：别把鸡蛋放一个篮子，篮子翻了还有兜底。家庭变体：在线一份、NAS 一份、云一份。够了。
删旧备份的时机：保留策略的另一面
keep-last=N 自动删旧备份，但"删"这个动作，值得多想一层。删早了，需要恢复时发现要的那份没了；删晚了，磁盘满了。保留数的设定，看"恢复窗口"：需要恢复"上个月"的数据吗？需要，保留数就要覆盖一个月。小备份 3 天一次、保留 3 份，覆盖 9 天；要覆盖一个月，保留 10 份。按"最长恢复窗口"倒推保留数，别拍脑袋。
另外，删之前确认"新备份是好的"。keep-last 是"先备新的，再删旧的"，顺序不能反。如果新备份失败了，旧的不删，宁可多占几天空间。备份脚本里，vzdump 成功返回 0 才走 prune，失败就告警+保留旧份。顺序，是备份脚本的生命线。
备份是信念，相信"数据会丢"，所以提前准备。不信的人，第一次丢数据时才信，那就晚了。信了，就自动化；自动化了，就演练。演练过了，才能睡安稳觉。
九、总结
PVE 备份体系三层：vzdump 定时备虚机/容器（大小分档、keep-last 保留）、宿主机配置每周打包（/etc/pve + /root 脚本）、全家备份时间表统一规划（错开 IO）。3-2-1 原则落地：在线一份、NAS 一份、异地一份（Google Drive 规划中）。记住两个版本号相关的坑（PVE 9 用 --prune-backups），以及最重要的：找机会做一次恢复演练，没演练过的备份不算数。
