故障排查

无法登录（纯 HTTP 部署）Copy Anchor Link

生产默认会话 cookie 带 Secure，纯 HTTP 下浏览器不保存 → 表现为登录“无反应”。 正确做法是加 TLS 反代；仅本地开发可 SB_INSECURE_COOKIE=1。

注册报“连接测试失败”Copy Anchor Link

界面不显示底层驱动错误（凭据保护）。看服务器日志的脱敏行： keyword_view 给出 host:port/db(user, sslmode)，据此逐项核对连通性/凭据/TLS。

Supabase/Neon 备份失败Copy Anchor Link

先按错误类分流：network 查连通性/池化端点（Supabase 用 5432 而非 6543；Neon 主机名 不能含 -pooler，预检警告即为此设）；client_version 与池化无关——它是找不到匹配 版本的 pg_dump 或缺少客户端，处理办法是升级/安装对应主版本的 postgresql-client， 换主机端口无济于事。

任务 interrupted 后没有续传Copy Anchor Link

续传只发生在启动时（ResumeRemotePhase）。确认重启后日志出现 resumed remote commit completed（成功）或 resume 相关的错误/ 跳过行；没有这些行不代表没尝试——续传只作用于同时满足 interrupted + 本地工件已 提交 + 远端 intent（uploading/committed）+ 目的地可用的任务。在“记录远端 intent 之前” 停机、local-only 部署、或 failed 任务都不在续传范围内，只能手动恢复或等新备份。 TTL 从 finished_at 起算，且启动顺序是先续传后清理，所以“超过 72h 就一定没了”不成立。

暂存涨满 / 新备份报 disk 类失败Copy Anchor Link

检查 supacove_staging_bytes 与目的地健康。失败工件在 SB_FAILED_ARTIFACT_TTL_HOURS 后自动回收；紧急时可手动删除 staging 中 failed 任务对应的密文，但这是不可逆的：上传失败的 工件保留着一次成功导出的完整密文，可能仍是唯一可恢复副本，且 failed 任务不会被启动 续传。删除前先核对任务与工件、把仍有价值的密文与 manifest 拷走保全；不要按通配符盲删， 也不要把 failed 状态本身当作安全删除依据（succeeded 的锚点更不可动）。

验证一直“未验证”Copy Anchor Link

验证默认关闭（SB_VERIFY_ENABLED=false）。开启需要 SB_VERIFY_IDENTITY_FILE 指向 0600 的 age 私钥文件。磁盘预算不足时验证落为 skipped 并说明原因。

Webhook 收不到事件Copy Anchor Link

投递日志看状态：单次投递有 10 秒 HTTP 超时，delivering 长时间滞留更可能是崩溃、 结果写入失败或 15 分钟租约等待（启动回收会重置）；dead 表示重试耗尽。 “发送测试”可区分配置问题与接收端问题。事件为至少一次语义，接收端应按 X-Supacove-Event-ID 去重（过渡期旧头 X-Supabackup-Event-ID 同值发送）。