Proxmox VE 使用指南

外观

进阶Backup Server数据丢失风险PVE 8.x / 9.x

资料核查：2026-09-29T00:00:00.000Z；尚无本站实机验证记录，请按文中的检查步骤确认本机结果。

PBS 数据存储维护：prune、GC 与 verify ​

装好 PBS 只是开始。数据存储（Datastore）的保留策略和垃圾回收（GC）节奏配错了，轻则磁盘占满，重则该保留的备份被永久删除，无法找回。这篇把这几个容易混淆的概念和它们之间的关系讲清楚。

开始之前 ​

已完成 部署 Proxmox Backup Server，能通过 Web UI 访问 PBS。

创建数据存储 ​

PBS 的 Web UI：Datastore → Add Datastore，有三种后端可选：

  • 目录型（Backing Path）：最基础的形式，指向一个本地挂载好的目录。
  • 可移动型（Removable Device）：绑定一个可插拔设备，卸载后相关的 verify/prune/GC 任务会自动跳过，等重新挂载再补跑。
  • S3 型：使用 S3 兼容对象存储，见 异地副本。

目录型 Datastore 要放在什么文件系统上

只支持 ext4、xfs、zfs，并且要求单个目录下能有至少 65538 个子目录——这排除了 ext3，也排除了关掉 dir_nlink 的 ext4。生产环境建议用 ZFS 或者有掉电保护的存储；读写压力不大的家庭实验室用 ext4 也可以。

Prune：只删元数据，不释放空间 ​

Prune 删除的是快照的清单索引（manifest、索引文件、日志），底层的数据块（chunk）还留在磁盘上——因为它们很可能被其他快照复用。所以"prune 跑完，看到的快照条目变少了，但磁盘占用没有立刻下降"是正常现象，真正回收空间的是 GC。

Prune 的保留规则和 配置备份任务与保留策略 里 PVE 端的分级保留是同一套逻辑：Keep Last / Hourly / Daily / Weekly / Monthly / Yearly，在数据存储的 Prune & GC 标签页设置调度和规则。

GC：真正回收空间，但有一段安全等待期 ​

GC 分两个阶段：

  1. 标记（mark）：遍历所有快照的索引文件，把它们引用到的每个数据块的访问时间（atime）刷新一遍。
  2. 清扫（sweep）：检查每个数据块的 atime，早于某个截止时间、且没有正在写入的备份任务引用它的，才会被删除；还在等待期内的会被报告为"待删除（pending removals）"。

这个截止时间（cutoff）取两者中较晚的一个：要么是当前还在运行的最早那个备份写入任务的开始时间，要么是 GC 开始前 24 小时 5 分钟。设这么长的等待期，是因为大多数文件系统用 relatime 挂载，atime 最多可能有一天没有更新——等待期短于这个窗口，会把还在用的数据块误判为"没人用"。

配错 Prune 或 GC，等于主动删除备份——这是数据丢失，不是"少占了点空间"

把保留规则改错了（比如手滑把 Keep Daily 从 7 改成 0），下一次 prune 跑完，本该保留的快照会直接从索引里消失；接下来 GC 一跑，这些快照曾经用到、且没有被别的快照引用的数据块会被永久回收，没有回收站。

预防措施：

  1. 改动保留策略之前，先手动跑一次 prune，看它列出的"将要删除"的快照列表——不要直接依赖定时任务第一次运行去验证配置对不对。
  2. 把确实重要、不想被自动清理的快照打上"受保护"标记（见 备份模式 里的受保护备份），prune 会跳过它们。
  3. 数据存储所在的文件系统本身也要有基本的容错能力（不要建在没有冗余的单盘上）——GC/prune 的配置失误叠加一次磁盘故障，是最坏的组合。

回退方式：一旦 GC 真正跑完并回收了数据块，这部分数据无法找回，只能退回到某一份异地副本，见 异地副本。这正是"备份的备份"——3-2-1 原则里的第二份拷贝——如此重要的原因，见 3-2-1 备份策略落地。

GC 的调度在 Prune & GC 标签页配置，也可以用 proxmox-backup-manager datastore update <datastore> --gc-schedule <日程> 命令行设置。多数场景每周跑一次是合理的起点。

Verify：定期确认数据没有静默损坏 ​

Verify 任务按日程定期检查已存储数据的完整性，可以选择跳过已经验证过的快照，或者过一段时间重新验证。read-threads/verify-threads（1–32，默认 1 和 4）控制并发度。

建议配置两个任务：一个较频繁（每天/每小时）只验证新增和刚过期的备份；一个每周或每月把全部数据重新验证一遍，因为磁盘会"位衰减（bit rot）"，只验证新数据发现不了老数据的静默损坏。手动触发：Content 标签页里的 Verify All，或者单个分组/快照旁边的校验图标。

检查结果 ​

  1. 数据存储页面显示的容量占用，明显小于"单份备份大小 × 保留份数"，体现出去重带来的空间效率。
  2. 手动跑一次 prune，输出的"将删除"列表符合你设定的保留规则，没有意外的条目。
  3. 手动跑一次 GC，日志里"pending removal"数量和最终回收的数据块数量在合理范围内，没有异常暴涨。
  4. 至少完整跑过一次 verify，结果是 OK，没有报告损坏的数据块。

常见问题 ​

Prune 跑完磁盘空间没变化。 正常现象，要等下一次 GC 才会真正回收，见上文。

GC 跑得很慢、CPU 占用高。 可以调大 gc-cache-capacity 加速，但更常见的原因是数据块数量本身就很大（小文件多、保留份数多），属于容量规划问题。

Verify 报告某个数据块损坏。 说明底层存储已经出现静默错误，先检查磁盘健康状况，同时立刻确认异地那份副本是干净的——本地这份的完整性已经不能完全信任了。

参考资料 ​

Proxmox VE 非官方中文使用指南，与 Proxmox Server Solutions GmbH 无隶属关系。