auto: sync OpenClaw config 2026-09-02 22:13
This commit is contained in:
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: "pbs-backup-stall-diag"
|
||||
description: "诊断 proxmox-backup-client 备份疑似停滞。增量备份跨慢盘(WSL /mnt)或大目录时进度滞后时用。判断真卡死与慢速推进。"
|
||||
status: proposal
|
||||
version: "v1"
|
||||
date: "2026-09-02T12:42:19.852Z"
|
||||
---
|
||||
|
||||
# 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 延迟，别据此误判。
|
||||
|
||||
## 网络通道补救（关键恢复）
|
||||
|
||||
慢速推进诊断通过后，若**长时间(如 15-20 分钟)仍无实质上传、最终报 `Error: timed out` + `HTTP/2.0 connection failed` + `catalog upload error - channel closed`**，且客户端与 PBS 本就在同一局域网——这通常是 **tailscale/中继传输通道在大数据量时卡死**，不是介质慢。恢复方法：
|
||||
|
||||
1. 查 PBS 服务器的局域网 IP：`ssh root@pbs01 'ip -4 addr show | grep "inet "'`（另一网卡常有如 `192.168.3.11`，tailscale 是 `100.115.x.x`）。
|
||||
2. 在客户端 ping 该 LAN IP；1ms 级延迟即同网可达。
|
||||
3. 把备份 repository 从 tailscale 主机名(`@pbs01`)改为 **LAN IP 直连**：`export PBS_REPOSITORY='backup@pbs!<token>@<LAN_IP>:<datastore>'`。
|
||||
4. 命中即整库备份从 20 分钟超时失败变为约 90 秒成功(增量复用 ~95%)。
|
||||
|
||||
服务端佐证：tailscale 失败时服务端 task 日志停在 `POST /dynamic_chunk` 后长时间无后续;LAN 直连时 `successfully added chunk ...` 连续刷新。
|
||||
注意：LAN 直连前提是客户端与 PBS 同网；跨地/异地时此地址不可达，需回退 tailscale——可让脚本动态判断(LAN ping 通则用 LAN,否则 tailscale)。
|
||||
+51
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: "pbs-backup-stall-diag"
|
||||
description: "诊断 proxmox-backup-client 备份疑似停滞。增量备份跨慢盘(WSL /mnt)或大目录时进度滞后时用。判断真卡死与慢速推进。"
|
||||
status: proposal
|
||||
version: "v1"
|
||||
date: "2026-09-02T13:05:33.862Z"
|
||||
---
|
||||
|
||||
# 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 延迟，别据此误判。
|
||||
|
||||
## 网络通道补救（关键恢复）
|
||||
|
||||
慢速推进诊断通过后，若**长时间(如 15-20 分钟)仍无实质上传、最终报 `Error: timed out` + `HTTP/2.0 connection failed` + `catalog upload error - channel closed`**，且客户端与 PBS 本就在同一局域网——这通常是 **tailscale/中继传输通道在大数据量时卡死**，不是介质慢。恢复方法：
|
||||
|
||||
1. 查 PBS 服务器的局域网 IP：`ssh root@pbs01 'ip -4 addr show | grep "inet "'`（另一网卡常有如 `192.168.3.11`，tailscale 是 `100.115.x.x`）。
|
||||
2. 在客户端 ping 该 LAN IP；1ms 级延迟即同网可达。
|
||||
3. 把备份 repository 从 tailscale 主机名(`@pbs01`)改为 **LAN IP 直连**：`export PBS_REPOSITORY='backup@pbs!<token>@<LAN_IP>:<datastore>'`。
|
||||
4. 命中即整库备份从 20 分钟超时失败变为约 90 秒成功(增量复用 ~95%)。
|
||||
|
||||
服务端佐证：tailscale 失败时服务端 task 日志停在 `POST /dynamic_chunk` 后长时间无后续;LAN 直连时 `successfully added chunk ...` 连续刷新。
|
||||
注意：LAN 直连前提是客户端与 PBS 同网；跨地/异地时此地址不可达，需回退 tailscale——可让脚本动态判断(LAN ping 通则用 LAN,否则 tailscale)。
|
||||
坑：**验证 LAN 是否解决时，别给 client 进程包一层人工 `timeout <秒>` 外壳**——proxmox-backup-client 收尾需把 catalog/finish 状态完整写回，若 timeout 在外壳里掐断了收尾，服务端会报 `backup ended but finished state is not set` 并删除已传完的快照(整库数据其实已传完)。恢复：去掉外层 timeout、让 client 自然结束即可完整成功。跑系统 service 则靠 service 的 `TimeoutStartSec` 兜底,不要额外加 client 级 timeout。
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
---
|
||||
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 延迟，别据此误判。
|
||||
@@ -82,6 +82,32 @@
|
||||
- PBS 快照时间为 **RFC3339 + UTC**（尾部 Z），如 `2026-08-21T07:59:08Z`，**无法改为本地时区**（文档依据 terminology.html）
|
||||
- 本地读取需 +8h 转换（Asia/Shanghai）
|
||||
|
||||
## 🤖 PC02 自动同步（配置于 2026-09-02）
|
||||
|
||||
### 连接信息
|
||||
- **pc02**：主机名 `xuan-main`，Windows+WSL2，Tailscale `100.115.195.189`
|
||||
- **SSH**：端口 **2222**，用户 `yangxuan`，密钥 `id_ed25519_pbs01_pc02`（免密）
|
||||
- **备份源在 WSL2 的 /mnt/d（Windows D盘 9P 慢速挂载）**，跨盘校验慢、耗时偏长（正常）
|
||||
|
||||
### 双备份配置（pbs01 触发）
|
||||
| 备份 | token | 源 | 目标 datastore | archive |
|
||||
|------|-------|-----|------|------|
|
||||
| 微信 | `backup@pbs!pc02_weixin` | `/mnt/d/yangxuan/Documents/xwechat_files/Backup/wxid_4931329313415` | weixin_backup | wexin.pxar |
|
||||
| library照片 | `backup@pbs!pc02_library` | `/mnt/e/library/library` | library | library.pxar |
|
||||
|
||||
- secret 存 PC02：`~/.config/proxmox-backup/pc02_weixin.pass`、`pc02_library.pass`（600）
|
||||
|
||||
### systemd 自动同步（pbs01 上）
|
||||
- **脚本**：`/root/scripts/auto-sync-pc02.sh`（先微信后 library 串行双备份）
|
||||
- **service**：`pc02-autosync.service`（oneshot，TimeoutStartSec=43200 即 12h）
|
||||
- **timer**：`pc02-autosync.timer`（开机后 150 秒触发）
|
||||
- **日志**：`/var/log/pc02-autosync.log`
|
||||
- **流程**：开机→150s→检测 PC02 在线(ping 189)→在线则免密 SSH(2222) 串行跑：微信备份 → library照片备份
|
||||
|
||||
### PC02 微信备份历史痛点
|
||||
- 微信/library 数据源在 /mnt/d,/mnt/e（Windows NTFS 跨盘 9P），proxmox-backup-client 增量校验每个文件时慢速 I/O，CPU 仅1-2%、进度慢、uploaded 0B 持续多分钟属正常
|
||||
- 全目录扫描可能比实际上传耗时更长
|
||||
|
||||
## 🔧 常见操作规范
|
||||
- 所有读写操作通过 `ssh root@100.115.195.195 '<命令>'` 执行
|
||||
- 只读命令直接执行；写/删/改命令必须先请示杨轩
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
name: "pbs-backup-stall-diag"
|
||||
description: "诊断 proxmox-backup-client 备份疑似停滞。增量备份跨慢盘(WSL /mnt)或大目录时进度滞后时用。判断真卡死与慢速推进。"
|
||||
---
|
||||
|
||||
# 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 延迟，别据此误判。
|
||||
|
||||
## 网络通道补救（关键恢复）
|
||||
|
||||
慢速推进诊断通过后，若**长时间(如 15-20 分钟)仍无实质上传、最终报 `Error: timed out` + `HTTP/2.0 connection failed` + `catalog upload error - channel closed`**，且客户端与 PBS 本就在同一局域网——这通常是 **tailscale/中继传输通道在大数据量时卡死**，不是介质慢。恢复方法：
|
||||
|
||||
1. 查 PBS 服务器的局域网 IP：`ssh root@pbs01 'ip -4 addr show | grep "inet "'`（另一网卡常有如 `192.168.3.11`，tailscale 是 `100.115.x.x`）。
|
||||
2. 在客户端 ping 该 LAN IP；1ms 级延迟即同网可达。
|
||||
3. 把备份 repository 从 tailscale 主机名(`@pbs01`)改为 **LAN IP 直连**：`export PBS_REPOSITORY='backup@pbs!<token>@<LAN_IP>:<datastore>'`。
|
||||
4. 命中即整库备份从 20 分钟超时失败变为约 90 秒成功(增量复用 ~95%)。
|
||||
|
||||
服务端佐证：tailscale 失败时服务端 task 日志停在 `POST /dynamic_chunk` 后长时间无后续;LAN 直连时 `successfully added chunk ...` 连续刷新。
|
||||
注意：LAN 直连前提是客户端与 PBS 同网；跨地/异地时此地址不可达，需回退 tailscale——可让脚本动态判断(LAN ping 通则用 LAN,否则 tailscale)。
|
||||
坑：**验证 LAN 是否解决时，别给 client 进程包一层人工 `timeout <秒>` 外壳**——proxmox-backup-client 收尾需把 catalog/finish 状态完整写回，若 timeout 在外壳里掐断了收尾，服务端会报 `backup ended but finished state is not set` 并删除已传完的快照(整库数据其实已传完)。恢复：去掉外层 timeout、让 client 自然结束即可完整成功。跑系统 service 则靠 service 的 `TimeoutStartSec` 兜底,不要额外加 client 级 timeout。
|
||||
Reference in New Issue
Block a user