重装后找不到备份脚本：如何定位并验证自定义备份链路
什么情况下会撞上这个问题
长期运行的自建服务器或 NAS 做过定期备份，备份逻辑是自定义脚本或插件，放在某个工作目录。系统重装、应用升级、容器重建或换机器后，发现备份任务似乎停了，不确定脚本是否还在、配置是否丢失、服务是否还活着。
典型表现：找不到脚本位置；找到了但不确定是否被当前环境加载；进程在跑但不知最近备份是否成功；云存储控制台看不到新对象。
本质是「配置资产散落在多个位置，重装后需要重新建立对应关系」。
为什么会这样：备份逻辑通常分三层存放
| 组成 | 典型位置 | 重装/升级时是否保留 |
|---|---|---|
| 触发入口（技能、定时任务、插件声明） | 工作目录下的配置目录 | 取决于是否在工作区内 |
| 实现代码（CLI、上传模块、路由） | 应用代码目录或独立服务目录 | 通常保留，除非被覆盖 |
| 运行时状态（进程、凭据、历史记录） | 进程表、环境变量、应用数据目录 | 最容易丢失 |
关键判断点：工作区内的文件通常随数据卷保留，而用户主目录、临时目录、会话数据往往在重装时被清空。 脚本放在工作区大概率还在；凭据存在会话或环境变量里就需要重新配置。
常见误区：把「服务在监听端口」等同于「备份正常」。端口探测只能证明进程活着，不能证明凭据有效、目标桶可写、候选目录正确。
怎么做：分四步定位并验证
第一步：按目录结构定位脚本
不要全盘搜索文件名，先按约定目录找：
find /path/to/app -maxdepth 4 -type d -name "skills" -o -name "plugins" 2>/dev/null
ls -lt /path/to/app/.agents/skills/看目录是否存在、修改时间是否接近记忆中的版本。目录在、文件完整，说明实现层没有丢。
第二步：确认实现代码与入口
技能声明文件通常只有几十行，负责描述调用哪个命令、接受什么参数。真正干活的是同级的实现目录。
sed -n '1,80p' /path/to/app/.agents/skills/<name>/SKILL.md
ls -l /path/to/app/services/<service>/backup/如果声明文件引用的路径在磁盘上不存在，说明代码层被覆盖或迁移过，需要从版本库恢复。
第三步：验证运行时状态
分开验证「服务活着」和「链路可用」。
ss -lntp | grep 20000
curl -sk -o /dev/null -w "%{http_code}\n" https://192.0.2.10:20000/backup
# 查看配置中的目标桶、区域、前缀是否存在，不要打印完整密钥判断标准：端口有监听、探测返回 401 或 200、配置文件里桶名和区域字段非空，三者同时满足才算服务层正常。任何一项缺失，先修这一层，不要急着跑备份。
第四步：跑一次最小上传并核对结果
不要直接跑全量。先选一个体积小、路径明确的文件做单次上传，然后到对象存储控制台按前缀核对。
node /path/to/app/services/<service>/backup/cli.mjs status
node /path/to/app/services/<service>/backup/cli.mjs upload --file /path/to/app/README.md在控制台确认对象键包含预期前缀、大小与源文件一致、修改时间是刚才。三项都对，说明凭据、网络、权限、路径映射全部打通。
怎么确认成了，怎么判断哪一步失败
- 目录不存在 → 实现层丢失，从版本库恢复；
- 目录在但声明文件引用的路径为空 → 配置与代码版本不匹配；
- 端口无监听 → 服务未启动，先看进程日志；
- 探测返回 5xx → 服务在但内部异常，看应用日志；
- 探测返回 401 且凭据正确仍无法上传 → 认证配置或权限策略问题；
- 上传命令成功但控制台无对象 → 前缀、桶名或区域配置错误，或上传到了另一个账号。
最可靠的确认方式是「控制台侧核对」，而不是只看命令退出码。
边界与代价
适用于脚本和配置都在本机、且目标存储可通过网络访问的场景。以下情况不适用或需额外处理：
- 凭据只存在于已清空的会话或环境变量中，必须重新签发，无法从磁盘找回；
- 备份范围限定在某个工作区，用户主目录下的数据本来就不在候选列表里，不要误以为漏备；
- 单文件有大小上限，超过上限的文件需要分片或排除，不能靠重试解决；
- 服务与业务入口共用认证时，改密码会同时影响两边，恢复前先确认影响面。
重装后重新启用备份前，先确认历史记录里最后一次成功上传的时间。如果间隔已经很长，说明期间的数据没有进云，需要评估是否补传，而不是直接从当前时间继续。
