排查失败的备份
备份失败时，Dockstash 大声告诉你并指出位置：带错误的警报邮件、项目卡片上的状态徽章、实时日志面板里完整的 restic 输出。本指南走一遍常见故障形态——红色运行、离线代理、沉默警报——和它们的修法。
怎么做
从项目卡片开始
Projects 页面按项目显示状态徽章、上次备份时间和大小。失败的运行同时以警报邮件送达，含错误和直达链接——从哪个开始都行。项目详情页直接展示上次失败的详情。
读这次运行的 restic 输出
打开失败运行的日志面板。最后几行几乎总能点名原因：authentication failed（SSH 密钥或数据库凭据）、no space left on device（存储机器满了）、connection refused（存储 VPS 不可达），或容器内转储命令的错误。
陈旧的 restic 锁会自愈
运行崩溃或服务器在备份途中重启，仓库可能留在锁定状态。无需干预：下一次运行会检测孤儿锁并自动执行 restic unlock。真正运行中任务持有的锁永远不会被打破。
代理项目：先查代理
舰队代理项目停止备份时，看 Fleet 页面。离线意味着心跳停了：到 VPS 上确认代理的两个容器都在跑、Dockstash 地址可达、令牌没有在未更新容器的情况下被轮换。日志里反复的 401 意味着某处还有老容器拿着已吊销的令牌在心跳。
docker compose -f docker-compose.agent.yml ps理解「没有备份运行」的警报
心跳警报意味着窗口内没有成功备份落地——什么都没失败，什么都没运行。常见嫌疑人：排程被停用、套餐没有排程、降级后项目被暂停、指派的代理离线。修好原因，下一轮绿色运行就清除警报。
常见 问题
备份失败一次、重试成功了。要在意吗？
看失败原因。任务用带上限的指数退避重试：瞬时网络抖动自愈。同一错误上的反复重试——磁盘渐满、SSH 不稳——值得在变成硬故障前真正修一修。
为什么我的第二个排程在等而不是在跑？
一个仓库同时一个任务，永远如此。并发 restic 操作会弄坏仓库，同一仓库上撞车的排程被刻意序列化。不同仓库并行运行。
我代理的 Add-Project 选择器是空的。为什么？
选择器读取代理上次心跳推送的快照。空意味着：代理还没上报过、某个项目目录并未真正挂进代理容器、或 Docker socket 代理不可达——选择器的横幅会告诉你是哪个。修好后点 Refresh now，不必等下一个发现周期。
如何证明仓库本身健康？
跑一个 check 任务。restic check 验证仓库结构；给个数据读取百分比还会实际读取并校验 pack 内容。通过要求退出码为零——没有假绿。
在哪里看演练为什么失败？
演练结果存有含差异数的详情消息，显示在 Restore drill 标签和警报邮件里。字节差异指向备份期间被改动的文件；行差异指向转储一致性——两种情况都把备份当作未证明，直到新一轮通过。