# 不论 AI 是否存在，homelab 都必须正常运行

## 核心思想
借助 AI 完成自己的任务时，一定要有无 AI 的替代方案。AI（如 Hermes Agent）只是加速器，不是拐杖——它本身也是 homelab 里运行的一个服务，会挂、会升级坏、会依赖出问题。关键路径如果寄生在 AI 上，AI 挂了基础设施跟着停；而最需要备份、最需要恢复能力的时刻，往往正是 AI 出问题的时刻。

## 五层独立性检查框架
判断一个自动化是否"无 AI 也能运行"，逐层检查：

### 调度层
任务由谁触发？如果调度器寄生在 AI 进程内（如 Hermes gateway 内置的 cron scheduler），AI 进程起不来 = 任务永不执行。替代方案：系统 crontab，与 AI 完全无关。

### 执行层
脚本是否依赖 AI 推理？纯脚本（no_agent）、标准系统工具（vzdump、rsync、scp）都满足。内容生成类任务天然依赖 AI，但数据收集层必须独立——AI 挂了只是不生成，数据不能丢。

### 存储层
备份目的地是否与源数据同机？单机单副本意味着硬盘损坏 = 数据归零。至少一份异地，且上传逻辑不依赖 AI 进程存活。

### 系统层
应用层备份之上还要有更底层的兜底：PVE 原生 vzdump 快照，不依赖任何脚本和 AI。

### 恢复层
灾难恢复入口（bootstrap 脚本）能否在 AI 不存在时手动执行？配置和文档是否以人可读的格式异地保存？

## 实践案例：备份调度自举死锁
审计发现备份脚本本身是 no_agent 纯脚本（执行层独立），但调度寄生在 Hermes gateway 的 cron scheduler 里。而备份的正是 Hermes 自己的状态（state.db、记忆、会话历史）——Hermes 因任何原因起不来，备份就静默停止。这是自举死锁：最需要备份的时刻反而没有备份。

修复：备份调度迁到系统 crontab，Telegram 通知改为脚本内 curl（显式走代理），Hermes 死活不再影响备份。同类检查：日记同步、健康检查等 no_agent 任务也应同样处理。

## 教训一：审计必须验证实际状态，不能信文档
skill 文档声称"远程备份 opt-in 关闭"，实际脚本无条件上传，异地备份一直在推、各保留 14 份。基于过时文档下结论会得出完全相反的判断。审计时验证三样东西：
- 脚本实际逻辑（grep 调用点，而不是读文档描述）
- 远端真实文件（sftp / S3 列举，看时间戳和字节数）
- 调度实际配置（crontab -l、系统服务）

## 教训二：独立脚本必须显式处理网络环境
Hermes 进程环境里有 http_proxy 走代理，但系统 crontab 是干净环境。Telegram API 在国内被墙，curl 直连会静默超时（-s 加 check=False 还会把错误吞掉）。独立脚本里所有外网调用都要显式指定代理，且失败要可见（打印错误、非零退出码），不能静默。

## 落地检查清单
- 备份调度在系统 crontab，不在任何 AI 进程内
- 备份 ≥ 2 份异地 + 1 份本地
- VM 有 vzdump 定期快照（PVE 原生，应用层之上的兜底）
- 恢复脚本可 curl | bash 手动执行，文档人可读
- 所有外网调用显式走代理，失败不静默


相关：[[pve-dual-nvme-storage-migration|pve-dual-nvme-storage-migration]]