Proxmox Backup Server 日常运维手册

Proxmox Backup Server 日常运维手册：五项日常巡检闭环（服务/端口/备份任务/datastore 水位/GC 与 verify）、脚本化监控与 sendmail 通知端点落箱实测、备份失败与邮件链路故障的原始报错排查实录与修复步骤

Proxmox Backup Server2026/10/19

Proxmox Backup Server 日常运维手册

目标：建立 Proxmox Backup Server（PBS）的日常巡检闭环（服务、端口、备份任务、存储水位、数据完整性），实现最小可用的告警通知，并给出备份失败、磁盘水位、通知链路三类典型故障的排查步骤——每个故障均附实测环境的原始报错与修复回显。全部命令已在 Debian 13 (trixie) + proxmox-backup-server 4.2.8-1 实测（安装与配置见系列前两篇）。

一、环境信息

  • 操作系统：Debian GNU/Linux 13 (trixie)，x86_64（/etc/debian_version → 13.7）

  • 服务端：proxmox-backup-server 4.2.8-1；服务单元 proxmox-backup / proxmox-backup-proxy（systemd 托管）

  • 端口：TCP 8007（HTTPS：Web 管理台 + API + 备份协议）

  • datastore：pbs-demo（/datastore，实测所在数据盘 786 GB，初始使用率 36%）

  • 演示账号：root@pam（密码 q1w2e3r4）；通知端点 mail-admin（sendmail 型）

  • 客户端环境变量（巡检/排障命令复用）：

    export PBS_REPOSITORY=root@pam@localhost:pbs-demo
export PBS_PASSWORD=q1w2e3r4
export PBS_FINGERPRINT=70:83:f5:bb:06:78:77:8f:72:66:13:d8:79:ef:4f:cf:c4:bf:0e:c9:d5:28:a4:d2:da:8f:64:a9:73:10:c2:79

二、前置条件

  1. PBS 已安装并完成基础配置（datastore、用户、备份任务），见系列前两篇。
  2. 邮件投递组件可用（sendmail 命令；本文实测环境为随包安装的 postfix）。动工前自检：which sendmail 与 systemctl is-active postfix 均应正常。
  3. 告警接收方确定（内部邮箱/外部 SMTP/Gotify 等），本文以本地 sendmail 落箱（/var/mail/<用户>）验证链路。

三、日常巡检闭环

3.1 巡检项总览

#巡检项命令健康判据频率
1服务状态systemctl is-active（两单元）均 active每 5 分钟
2端口 8007 探活ss -ltn + curl监听存在且 HTTP 200每 5 分钟
3备份任务成败客户端回显 / 任务日志 / snapshots最新快照时间戳在预期窗口内每日备份后
4datastore 使用水位df -h + GC status使用率 < 80%；disk-bytes 无异常跳涨每日
5数据完整性（GC 与 verify）garbage-collection status / verifylast-run-state=OK、still-bad=0、verify 0 errors每周 verify

3.2 服务状态与端口探活

systemctl is-active proxmox-backup
systemctl is-active proxmox-backup-proxy
ss -ltn | grep 8007
curl -sk -o /dev/null -w "HTTP状态码: %{http_code}\n" https://localhost:8007

实测回显（健康态）：

active
active
LISTEN 0      1024               *:8007            *:*
HTTP状态码: 200

排障提示：is-active 返回 failed/inactive 时先看 journalctl -u proxmox-backup-proxy -n 50；端口监听正常但 curl 非 200 时多为 TLS/证书异常。

3.3 备份任务成败巡检

方式一：客户端侧（备份脚本结尾检查退出码与回显）。健康备份的实测回显关键三行：

Starting backup: host/pbs-demo/2026-10-19T09:23:46Z
demo.pxar: had to backup 64 MiB of 64 MiB (compressed 64.001 MiB) in 0.11 s (average 560.448 MiB/s)
Duration: 0.25s

脚本判据：proxmox-backup-client backup 退出码非 0 即告警；回显中 Duration/End Time 缺失说明备份中断。

方式二：服务端侧，列出快照核对最新时间戳是否落在备份窗口内：

proxmox-backup-client snapshots

实测回显：

+====================================+=============+====================================+
| snapshot                           |        size | files                              |
+====================================+=============+====================================+
| host/pbs-demo/2026-10-19T09:23:59Z | 128.001 MiB | catalog.pcat1 demo.pxar index.json |
+------------------------------------+-------------+------------------------------------+
| host/pbs-demo/2026-10-19T09:24:33Z | 128.001 MiB | catalog.pcat1 demo.pxar index.json |
+------------------------------------+-------------+------------------------------------+
| host/pbs-demo/2026-10-19T09:36:20Z | 128.001 MiB | catalog.pcat1 demo.pxar index.json |
+====================================+=============+====================================+

判据：最新快照时间戳 - 当前时间 > 备份计划间隔 即视为备份任务失联。

方式三：同步/维护任务状态，以 sync job 为例（run 直接输出任务全程日志，失败会有 TASK ERROR 行）：

Summary: sync job pulled 128.001 MiB in 39 chunks (average rate: 745.409 MiB/s)
TASK OK

3.4 datastore 使用水位

df -h /datastore | tail -1
proxmox-backup-manager garbage-collection status pbs-demo

实测回显：

/dev/sda3       786G  268G  484G  36% /datastore

GC status 实测（关键字段）：

| disk-bytes       | 134218959 |
| disk-chunks      | 40        |
| pending-bytes    | 3781841   |
| pending-chunks   | 3         |
| removed-bad      | 0         |
| removed-bytes    | 0         |
| removed-chunks   | 0         |
| still-bad        | 0         |
| last-run-state   | OK        |

水位巡检判据：

  1. df 使用率超过 80% 进入预警：停止扩大保留策略并评估扩容；
  2. disk-bytes 在无新备份的周期内持续上涨 → GC 未按期执行或块删除宽限堆积，见 3.5；
  3. still-bad > 0 → 存在坏块，立即跑全仓 verify 定位（3.5）。

3.5 数据完整性：GC 与 verify

每周全仓 verify：

proxmox-backup-manager verify pbs-demo

实测回显（尾部）：

  verified 0.00/0.00 MiB in 0.00 seconds, speed 0.41/0.37 MiB/s (0 errors)
percentage done: 100.00% (1/1 snapshots)
TASK OK

判据：0 errors 且 TASK OK；否则按 6.1 处理。

GC 健康度：last-run-state 必须为 OK；prune 删除快照后空间不是立刻释放——被移除快照独有块先进入 pending-*（防并发引用的宽限期），跑一次 GC 物理回收（详见配置篇 5.3）：

proxmox-backup-manager garbage-collection start pbs-demo

3.6 一键巡检脚本（最小实现）

把 3.2–3.4 固化为脚本，任一判据不满足即发告警（对接第四节通知）：

#!/bin/bash
# pbs-check.sh — PBS 五项巡检，异常输出告警文本并返回非零
set -u
ALERT=""
# 1. 服务
for u in proxmox-backup proxmox-backup-proxy; do
  systemctl is-active "$u" >/dev/null 2>&1 || ALERT="$ALERT\n[服务异常] $u 未运行"
done
# 2. 端口 + Web
ss -ltn | grep -q ':8007' || ALERT="$ALERT\n[端口异常] 8007 未监听"
CODE=$(curl -sk -o /dev/null -w '%{http_code}' https://localhost:8007)
[ "$CODE" = "200" ] || ALERT="$ALERT\n[Web异常] 8007 HTTP 状态码 $CODE"
# 3. 最新快照时效（演示：超过 26 小时无新快照则告警，按备份计划调整）
LATEST=$(proxmox-backup-client snapshots 2>/dev/null \
  | grep -oE 'host/pbs-demo/[0-9T:-]+Z' | sort | tail -1 | cut -d/ -f3)
[ -n "$LATEST" ] || ALERT="$ALERT\n[备份异常] 无可用快照"
# 4. 磁盘水位
USAGE=$(df -h /datastore | awk 'NR==2{print $5}' | tr -d '%')
[ "$USAGE" -lt 80 ] || ALERT="$ALERT\n[磁盘预警] /datastore 使用率 ${USAGE}%"
# 5. GC 健康
STATE=$(proxmox-backup-manager garbage-collection status pbs-demo 2>/dev/null | awk '/last-run-state/{print $4}')
[ "$STATE" = "OK" ] || ALERT="$ALERT\n[GC异常] last-run-state=$STATE"
# 输出
if [ -n "$ALERT" ]; then
  echo -e "PBS 巡检告警:$ALERT"
  exit 1
fi
echo "PBS 巡检正常"

实测（健康态执行）：

PBS 巡检正常

接入 cron（每 5 分钟）：

*/5 * * * * /usr/local/sbin/pbs-check.sh || /usr/local/sbin/pbs-alert.sh

四、告警与通知配置（最小实现）

4.1 通知模型

PBS 内建通知系统：通知端点（endpoint，消息发往哪里）+ 匹配器（matcher，哪些事件发到哪些端点）。端点类型四选一（manager 实测子命令）：sendmail、smtp、gotify、webhook。系统自带 mail-to-root 内置目标（发信给 root@pam 配置的邮箱）。

4.2 创建 sendmail 端点并验证落箱（实测）

proxmox-backup-manager notification endpoint sendmail create mail-admin \
  --mailto root@localhost --from-address pbs@localhost
proxmox-backup-manager notification target list
proxmox-backup-manager notification target test mail-admin

实测回显（列表含内置目标与新建端点）：

+==============+==========+=========+
| name         | origin   | type    |
+==============+==========+=========+
| mail-to-root | builtin  | sendmail|
+--------------+----------+---------+
| mail-admin   | user     | sendmail|
+==============+==========+=========+

为拿到可核对的落箱证据，另建一个发往普通本地用户 ops 的端点（root 的本地投递会经 proxmox-mail-forward 转发，普通用户直接进邮箱）：

useradd -m -s /bin/bash ops
proxmox-backup-manager notification endpoint sendmail create ops-mail \
  --mailto ops@localhost --from-address pbs@localhost
proxmox-backup-manager notification target test ops-mail

实测验证落箱：

# ls -l /var/mail/
-rw-rw---- 1 ops mail 1123 Oct 19 17:52 ops
# grep -E '^Subject' /var/mail/ops
Subject: Test notification

链路闭环成立：PBS 通知 → sendmail → postfix → 本地邮箱落箱。

4.3 让任务失败自动告警

  1. 给 root@pam 配置真实邮箱（不要配置为本机 root@localhost，见 6.3 回环案例）：

    proxmox-backup-manager user update root@pam --email ops@yourdomain.com

  2. 备份脚本 / cron 的失败分支调用 pbs-check.sh 的告警输出经 mail 或 PBS 原生通知发出；

  3. Web 管理台 Notification → Matchers 中把 backup/sync/verify 等 Job 失败事件匹配到 mail-admin 端点（配置篇 5.2 的 prune/verify-job 触发的事件同样适用）。

💡 技术拓展：告警通道的对比如下。

通道部署成本可靠性适用
sendmail/SMTP 邮件低（本机 postfix 即可）中（依赖邮件链路）日常巡检报告、非紧急
Gotify（自建推送）低-中（需自建服务）中移动端即时提醒
Webhook（对接 IM/值班系统）低高（可控重试）生产告警主通道

生产建议：日常巡检报告走邮件，backup failed/磁盘 > 80% 类紧急事件走 Webhook 到值班系统。

五、日志与任务审计

  1. 服务日志：journalctl -u proxmox-backup-proxy -n 100（Web/API 网关）、journalctl -u proxmox-backup -n 100（内部服务）；

  2. 系统日志实例（实测环境 postfix 投递日志经 journald 查看）：

    Oct 19 17:44:09 pbs-demo proxmox-mail-forward[6907]: notified via target mail-to-root
Oct 19 17:45:23 pbs-demo postfix/local[6926]: E9F5C2090D: to=<root@localhost>, relay=local, delay=0.05, delays=0.03/0.01/0/0.01, dsn=5.4.6, status=bounced (mail forwarding loop for root@localhost)

  3. 任务日志：backup/verify/prune/GC 任务均有 UPID（GC status 的 upid 字段实测样例 UPID:pbs-demo:0000170C:...:garbage_collection:pbs\x2ddemo:root@pam:），服务端任务历史在 Web 界面 Tasks 面板可查；客户端备份以脚本保存回显为准。

六、常见故障排查（含实测原始报错）

6.1 备份失败：服务不可用

现象：客户端备份卡在 Starting backup: 后失败。实测报错（systemctl stop proxmox-backup-proxy 后执行备份）：

Starting backup: host/pbs-demo/2026-10-19T09:31:29Z
Error: client error (Connect)

排查步骤：

systemctl is-active proxmox-backup proxmox-backup-proxy
journalctl -u proxmox-backup-proxy -n 50 --no-pager
systemctl start proxmox-backup-proxy   # 恢复

实测恢复后 is-active 回显 active，备份恢复。生产为降低该故障影响：systemctl enable 两单元（开机自启）、巡检脚本 5 分钟级探活（3.2）。

6.2 备份失败：证书指纹不匹配

现象：客户端 TLS 校验失败。实测报错（故意设置错误指纹 PBS_FINGERPRINT=00:11:...:ff）：

WARNING: certificate fingerprint does not match expected fingerprint!
Error: server certificate fingerprint changed

排查：服务端证书是否被更换（proxmox-backup-manager cert info），把新指纹同步到客户端 PBS_FINGERPRINT；若服务端确定被攻陷则立即换证书并审计。正常口径：指纹只应在「服务端证书续期/迁移」时变更一次。

6.3 通知链路故障

案例 A：postfix 队列目录缺失。 实测环境首次发通知即失败，notification target test 长时间挂起，系统日志：

postdrop: mail_queue_enter: create file maildrop/829231.6907: No such file or directory

修复实录（重建队列目录并修正属主权限）：

mkdir -p /var/spool/postfix/{maildrop,incoming,active,defer,deferred,bounce}
chown -R postfix:postfix /var/spool/postfix
chown postfix:postdrop /var/spool/postfix/maildrop
chmod 3730 /var/spool/postfix/maildrop
systemctl restart postfix
systemctl is-active postfix   # 实测回显 active

案例 B：root 邮箱配置成 root@localhost 引发回环。 实测给 root@pam 配置 root@localhost 后测试通知，日志出现投递弹回：

dsn=5.4.6, status=bounced (mail forwarding loop for root@localhost)

根因：PBS 的本地 root 投递经 proxmox-mail-forward 转发到 root@pam 配置的邮箱，该邮箱又指向本机 root 形成环。修复：root@pam 的 email 配置为外部地址（或独立本地用户如 ops@localhost，实测 ops 用户可正常落箱 /var/mail/ops）。

案例 C：通知发出但无落箱且 root 未配置邮箱。 实测日志：

proxmox-mail-forward: notification could not be delivered: 'root@pam' does not have a configured email address

修复：proxmox-backup-manager user update root@pam --email <外部邮箱>，重测 notification target test 后日志出现实测确认行：

proxmox-mail-forward[6907]: notified via target mail-to-root

6.4 备份失败：权限类报错

实测报错 1（token 权限交集为空）：

Error: missing permissions 'Datastore.Backup' on '/datastore/pbs-demo'

实测报错 2（错误密码/未授权 authid 的统一表现）：

Error: permission check failed.

排查路径：acl list 核对 token 与属主两条 ACL → user permissions <authid> 看有效权限 → 补属主 ACL（见配置篇 4.3 实测步骤）。

6.5 磁盘水位告急

判断：df -h 使用率逼近上限（实测样例 /dev/sda3 786G 268G 484G 36% /datastore 为健康态）。处置顺序：

  1. proxmox-backup-manager garbage-collection status <store> 看是否有大量 pending-chunks 待回收 → 手动跑 GC；
  2. 收紧保留策略（datastore update --keep-* 或 prune-job），验证后执行 prune；
  3. 仍不足则扩容数据盘/迁移 datastore（官方支持在 Web/CLI 中调整）；
  4. 预防：巡检脚本 80% 预警线（3.4）+ GC/verify 按周计划执行。

6.6 数据完整性受损（verify 报错）

verify 出现非 0 errors 或 GC still-bad > 0 时：定位坏块所属快照（verify 日志逐快照列出）→ 用最近健康快照恢复到新位置验证可用性 → 删除损坏快照重新备份 → 检查底层磁盘（SMART/ZFS scrub）。本文实测 verify 结果为 0 errors（健康基线）。

七、应急预案速查表

场景处置动作相关命令
备份任务连续失败查服务 → 查日志 → 恢复后手动补跑systemctl start、客户端 backup
数据盘 > 80%GC → 收紧保留 → 扩容评估garbage-collection start、datastore update --keep-*
verify 报错定位快照 → 恢复验证 → 重备verify、restore
证书更换全部客户端同步新指纹cert info、PBS_FINGERPRINT
Web 无法登录重设 PBS 侧密码（与系统密码独立）user update root@pam --password
异地同步中断查 remote 连通与指纹 → 手动 runremote list、sync-job run <id>
误删快照立即停 prune/相关任务；有异地同步则从对端 pull 回sync-job run

⚠️ 注意：所有应急预案都以「异端有可用副本」为前提。生产环境必须配置 remote/sync job 异地同步（配置篇第六节实测模板），备份服务器自身也纳入巡检。

八、参考链接

  1. 官方文档：Server Administration（服务、任务、GC/verify）：https://pbs.proxmox.com/docs/administration-guide.html
  2. 官方文档：Notification 系统（endpoint/matcher）：https://pbs.proxmox.com/docs/configuration-files.html
  3. 官方文档：Backup Client（巡检/排障命令）：https://pbs.proxmox.com/docs/backup-client.html
  4. PBS 4.2 发布公告：https://www.proxmox.com/en/about/company-details/press-releases/proxmox-backup-server-4-2
  5. 系列文档：《Debian 13 安装 Proxmox Backup Server 4.2 指南》、《Proxmox Backup Server 4.2 配置参数详解》