---
name: "pbs-backup-stall-diag"
description: "诊断 proxmox-backup-client 备份疑似停滞。增量备份跨慢盘(WSL /mnt)或大目录时进度滞后时用。判断真卡死与慢速推进。"
status: proposal
version: "v1"
date: "2026-09-02T11:44:27.567Z"
---

# PBS 备份停滞诊断

当 proxmox-backup-client 备份在日志里长时间停在同一个 `processed X GiB ... uploaded 0 B`，判断是**真卡死**还是**慢速推进**（常见于跨盘/大目录增量备份）。

## 背景

增量备份只传变化数据，但**校验变化前要逐文件读取对比**。当源在慢速介质（WSL 的 `/mnt/d`、`/mnt/e` Windows NTFS 挂载，走 9P 协议），或含海量小文件时，I/O 成为瓶颈：表现为 CPU 占比低（约 1-2%）、processed 长时不变、uploaded 0 B。这是**预期的慢，不是故障**。

单看 `/var/log/<name>-autosync.log` 无法区分——它只在整文件边界更新。

## 诊断过程

1. 定位进程：`pgrep -f "proxmox-backup-client backup"` 取 PID。
2. 看进程状态与 CPU（S 状态 + 低 CPU = 等在 I/O，非僵死）：
   `ps -o pid,stat,pcpu,etime -p <PID>`
3. **确认在推进（关键）**：查它正打开的文件——
   `ls -l /proc/<PID>/fd | grep -E "/mnt|pxar"`
   若 fd 指向源目录深层具体文件（如 `.../Media/<id>_m...`）且打开时间在变化，说明正在逐个读文件做校验。
4. 看是否已连到目标：`ss -tnp | grep :8007`，有 ESTAB 即在与 PBS 通信。
5. 结合源规模估算：`du -sh <源>` + `find <源> -type f | wc -l`。文件数以千计、源在 /mnt 跨盘时，耐心等，勿贸然 kill。

## 判定

- 进程 S/Ssl 状态、CPU 低、fd 在变化指向源文件、连 :8007 → **慢速推进，等待**。
- 进程消失、或 fd 长期不动且无网络、或 CPU 也 0 且无 I/O → 才考虑真卡死，需 kill 重跑。

## 坑

- 服务端快照目录里只看到空的 `*.tmp_didx`、0 字节，不代表卡死——内容要等本地上传阶段才开始写入。
- 日志时间戳滞后是 systemd `StandardOutput=append` 的 flush 延迟，别据此误判。