测试机 47.251.104.47 的每日备份(`/root/pac-backup.sh`,cron 0 4 * * *)
连着两次(08-11、08-15)在 04:30 前后失败,backup.err 里是
「server closed the connection unexpectedly」。翻 postgres 容器日志才看清:

  PANIC: could not write to file "pg_logical/replorigin_checkpoint.tmp":
         No space left on device
  checkpointer process was terminated by signal 6: Aborted

⇒ **不是 PG 的毛病,是这个脚本撑爆的盘。** 轮转写在 dump 成功之后,
  于是写第 4 份(~12G)时旧 3 份 33G 全程占着 → 盘满 → PG 当场 PANIC、
  整个实例重启走 WAL 崩溃恢复 → pg_dump 连接跟着断。

⚠️ 最难受的一点:脚本删掉 .partial 之后空间就回来了、库自己恢复完毕,
  **白天查什么都正常**,所以连崩两次都没人发现。
⚠️ 崩溃恢复还清空了 pg_stat_*(统计文件不跨崩溃保留)——
  之后查到的死元组数只是崩溃后攒的,⛔ 别拿它判断表膨胀。

两处结构性修改:
① **先轮转、再 dump**:留 KEEP-1 份进 dump,写完正好 KEEP 份。
   峰值从 (KEEP+1)×份 压到 KEEP×份 —— 不再需要凭空多出一份的余量。
   代价:dump 失败时手上只剩 KEEP-1 份;比起把库撑崩,可接受。
② **动手前先算够不够**,不够就不开工并大声记日志。
   ⛔ 不许为腾地方自动多删旧备份 —— 少留几天恢复窗口是人的决定,不是脚本的。
   预检在**删之前**算(用"轮转能腾出多少"做加数),不够时一份都不动。

另外:KEEP 3→2(盘 197G / PG 卷已 75G / 一份 dump 12G,KEEP=3 两天就回到
5G 余量,正是事故前的水位);加 --dry-run(只算不动手);backup.err 超 5M 自转。

📌 顺带把它收进仓库:此前**只存在于服务器上**,而 scripts/backup-db.sh 是另一个
   本地临时用的脚本,两者早已各走各的。README 写清谁是谁。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>