PBS 4.2 于 2026 年 4 月 29 日发布，版本日期可在官方发布说明核实。本周先检查 prune 和 GC 是否按预期运行，再分别核对 PBS 状态与底层文件系统；不要只看快照列表或去重率，也不要手动删除 .chunks。若文件系统确实无空间，或 GC 已无法运行，先确认存储后端、备份风险和恢复路径，再按官方说明安全释放空间或增加容量。
独立维护 PBS、发现 datastore 占用持续增长的管理员，可以按文中的顺序区分任务问题与存储问题。
同时维护多套客户备份的 MSP 运维人员，应把保留策略、任务记录和容量告警纳入变更核查。
规划多租户备份存储的小型 IDC 技术负责人，可以据此复核容量边界与备份目标。
最后更新于 2026 年 10 月 28 日；版本日期核对自官方发布说明和官方版本路线图，排查步骤核对自 PBS 4.2 官方文档。
先判断 PBS 备份库空间不足来自任务还是磁盘
快照列表展示备份条目，不等于文件系统的实际占用；去重信息也不是“可以回收的空间”计数。PBS 使用数据块和索引管理备份，不同快照可能引用相同数据块，因此只看快照数量、快照显示大小或 deduplication 数值，无法判断哪些文件可删除，或具体能释放多少空间。
备份快照删掉后，磁盘空间为什么没有马上下降？prune 会依据保留规则移除不再保留的快照元数据；只有不再被其他备份引用的数据块，才可能由 GC 清除。符合条件的数据块也要经过 GC 处理，不能把界面里看不到某个快照，等同于底层磁盘立即腾出空间。PBS 官方维护文档说明了 prune 与 GC 的不同作用及数据块回收过程。
先进行只读核查，并保存命令结果：
proxmox-backup-manager datastore list
proxmox-backup-manager datastore show <datastore>
proxmox-backup-manager prune-job list
proxmox-backup-manager garbage-collection list
proxmox-backup-manager garbage-collection status <datastore>
df -hT
PBS 命令用于查看 datastore 配置及维护任务状态；df -hT 用于核对文件系统总量、已用量和剩余量。PBS 4.2 命令参考列出了 GC 任务列表、启动与状态查询命令；执行启动命令前，先检查是否已有维护任务在运行。(命令参考)
| 当前看到的状态 | 先做什么 | 决策方向 |
|---|---|---|
| prune 没有计划、没有成功记录，或保留策略与预期不同 | 核对任务目标 datastore、保留规则、最近日志和变更记录 | 修正任务或策略；确认影响范围后再执行 |
| prune 正常，但 GC 未运行或最近执行失败 | 查 GC 计划、任务结果、错误信息及文件系统可用空间 | 先处理 GC 未运行的原因；不要手动删数据块 |
| PBS 显示占用异常，同时文件系统也接近或达到容量边界 | 核对挂载点、设备、文件系统类型、告警与空间趋势 | 判断能否安全扩容或释放空间 |
| GC 因存储无空间而无法运行 | 暂停未经确认的删除或重建操作，保存日志并确认恢复路径 | 依据后端官方说明制定处置方案；必要时先增加可用容量 |
独立管理员：先核对 prune 与 GC 的任务记录
prune 根据保留规则选出需要保留的备份快照，并移除不再保留快照的元数据；GC 检查数据块的引用情况，再处理符合回收条件的数据块。两者处理的对象和时点不同，所以 prune 成功不代表磁盘已经回收，GC 计划存在也不代表任务已成功运行。官方维护文档提供了相关行为说明。
按顺序对照任务配置、最近执行结果与错误记录。确认 prune job 指向正确 datastore，保留规则没有被意外改动；再检查 GC 最近状态、启动时间和失败信息。PBS 命令参考支持查询 GC 状态及启动指定 datastore 的 GC，但手动启动前，应先核实它不会与正在进行的维护任务冲突。
再把 PBS 侧状态与文件系统占用并排核对。如果 prune 按计划完成、GC 也成功，而文件系统使用量仍持续增长，就要继续追查新增备份、其他目录占用、文件系统预留，或挂载位置是否与预期一致，而不是反复调低保留天数。
MSP：把客户数据风险与排障动作分开
多客户环境中，一个 datastore 可能承载多个客户的备份；如果保留规则修改或删除操作的影响范围不明，就可能改变仍在业务策略内的数据留存。
先记录客户、datastore、任务 ID、告警时间、最近一次成功备份、prune 和 GC 结果，以及正在执行的变更。再确认保留策略是否符合客户约定，核查任务是否漏跑、失败或指向错误存储。在责任人确认影响范围与恢复条件之前，不要对共享 datastore 执行未经批准的删除。
快照条目减少了，但空间变化不明显，是否说明 GC 出错？不一定。仍被其他快照引用的数据块不会因为删除一个快照而变成可回收数据；此外，底层文件系统和 PBS 对占用的统计口径也可能不同。应结合 GC 结果和文件系统状态判断，不要凭某个页面上的单一数字定性。
小型 IDC：按存储后端选择容量视图
PBS 4.2 官方存储文档列出了本地文件系统 datastore 与 S3 兼容对象存储后端。排查前先识别 datastore 类型和实际路径，再选择对应的容量检查方式；不同后端的容量视图不能互相替代。官方存储文档
- ext4 或 XFS：核对挂载点和
df -hT结果。需要定位目录级占用时，先确认目标路径，再使用只读目录统计工具。官方存储文档还说明，datastore 文件布局对目录支持有要求，需支持至少 65,538 个子目录项；不要因目录看起来异常就改动其内部结构。 - ZFS：分别核对池、数据集、预留空间和 PBS datastore 路径。池仍有剩余空间，不一定表示挂载给 datastore 的数据集也有足够可用空间；同时记录快照与预留设置，避免只依据一条
df输出下结论。 - S3 后端：区分对象存储的容量与告警，以及 PBS 本机持久化缓存的文件系统空间。官方文档说明，S3 datastore 仍需要本地缓存；对象端写满时，部分清理操作也可能失败，因此应按官方针对 S3 的说明处理，不能套用本地
.chunks排障方式。官方还给出 S3 缓存容量的建议范围为 64 GiB 至 128 GiB，此值针对缓存规划，并不代表所有环境的 datastore 容量要求。
社区在 2026 年 9 月 22 日有一则 PBS 满盘排查个案，发帖者描述了自己的存储告警。该帖子只代表一个环境的排查过程，不能据此断言 PBS 4.2 存在普遍满盘缺陷，也不能把论坛回复里的临时建议当作通用修复。查看该社区个案
按故障状态决定修任务、释放空间或扩容
PBS datastore 快满时，先清理还是扩容？先看证据：任务未运行或保留策略未生效，优先修复任务；任务正常但实际文件系统容量不足，则评估扩容或经批准的安全释放方案。两类问题可能同时存在，因此增加容量不能替代修正错误配置，减少保留也不能被当成无风险操作。
磁盘空间耗尽后 GC 无法运行，该从哪里开始？先确认失败发生在哪个后端、哪个挂载点，以及系统是否还有受控的可用空间供任务操作；随后查阅适用于该后端的官方恢复说明。若无法确认安全回退路径，先暂停破坏性变更，保留日志和配置，再安排维护窗口并与数据负责人确认。
特别注意：不要手动删除、移动或重命名 .chunks 内的数据。PBS 依赖索引和数据块引用关系管理备份，文件级改动可能破坏现有备份或恢复能力。涉及清理、重建文件系统、变更 ZFS 池或处理 S3 对象时，先核对官方文档、备份副本、维护窗口与恢复条件；PBS 官方存储文档还说明，移除 datastore 配置与删除其底层内容是不同操作，命令参数必须仔细核对。
修复后逐项验证，再依据实际增长重算容量
- [ ] 保存变更前的 prune 和 GC 任务记录、datastore 配置与文件系统状态，注明受影响的客户或租户。
- [ ] 确认修复后 prune job 指向正确 datastore，保留策略与已批准的留存要求一致。
- [ ] 核对 GC 的运行结果与错误日志；如果 GC 仍失败，停止重复执行，先依据错误和后端状态定位原因。
- [ ] 重新读取 PBS 的 datastore 状态和底层文件系统容量；ZFS 或 S3 后端还要核对各自的池、数据集、缓存或对象存储视图。
- [ ] 检查后续备份是否按计划完成，并确认任务日志没有新的容量告警。
- [ ] 记录实际备份增长、保留策略、可用空间变化和扩容前提，用持续观测结果更新容量预算，不用单个社区案例推算所有环境。
PBS 官方维护文档说明，prune 与 GC 可以按 datastore 配置计划运行；实际回收结果取决于备份数据的引用关系与底层存储情况，因此不能预先承诺固定释放量。
如果你需要独立备份目标，可以先根据实际备份增长、保留策略、磁盘冗余方式、带宽和机外备份安排评估存储边界，再查看 OVN Cloud 的独享服务器配置选项，并以 OVN Cloud 当前方案与计费信息核对可选配置。独享 AMD 物理服务器适合需要自行管理存储布局、长期运行并控制资源边界的场景，但它不会自动代替 PBS 运维或异地备份服务。若你的需求只是短期临时存放少量数据，或无法自行维护冗余与机外副本，先保留现有方案并补齐容量监控，可能比迁移到独立服务器更合适。