与Obsidian同步的博客搭建（六）——持续运维
网站上线后，真正花时间的不是第一次部署，而是持续区分“内容变化”“代码变化”“配置变化”和“互动数据变化”。四类变化采用不同备份与回滚路径，避免一个小改动演变成整站重建。
内容更新流程
- 在 Obsidian 编辑 Blog、Wiki、Project 或 Daily。
- 使用 Bedic Publisher 明确发布或更新修订。
- 等待 Obsidian Sync 完成。
- Headless Sync 把变化写入 Server Mirror，并产生队列事件。
- Publisher 构建候选；没有公开修订变化时返回
noop。 - 候选通过后原子激活，旧 Release 保留。
普通草稿编辑不会改变网站，取消发布也不会删除源笔记。
代码更新流程
代码更新先在本地运行类型检查、Astro 诊断、单元测试和部署契约，再构建带哈希的部署包。生产机重复 Linux 测试后安装新 runtime，保留旧 runtime 与回滚记录。CSS 或组件改动还需要真实桌面/手机视口截图和控制台检查。
每日与周期检查
- Caddy、Publisher、互动、图片桥和同步服务是否 active；
- Publisher health 的 release-id、内容数与警告；
- 队列是否有长期 pending/failed；
- Waline SQLite
integrity_check与在线备份哈希； - 磁盘中 Release、构建缓存和图片对象增长；
- 公共首页、搜索、RSS、Atom、sitemap 与 404/410 行为。
常见故障
内容没有更新
先看 publish_revision 是否增加，再看 Sync、队列和候选警告。不要直接编辑 Server Mirror，它不是权威数据源。
新版本构建失败
保留日志和候选目录，修复源文件或代码后重试；current 不会改变。若已经激活后发现视觉问题，直接切回上一 Release。
评论不可用
确认静态文章仍能打开，再单独检查回环 Waline、Caddy 代理与 SQLite。互动故障不应触发内容回滚。
图片上传失败
检查 Android 配置中的端点、认证令牌、文件类型与 12 MiB 限制；令牌只存在于移动配置和服务器秘密文件，不进入文章、仓库或公开 Release。
备份与恢复
Vault 依赖 Obsidian Sync 历史与本地完整备份；Publisher 依赖保留的 runtime、state 和 Release；互动数据库使用 SQLite 在线备份并定期做真实恢复演练。只有“备份文件存在”不算通过，恢复后的哈希、完整性和服务启动都必须验证。
这套长期维护方式的核心是：权威内容始终在 Obsidian，公开版本始终可追踪，动态互动始终独立，任何失败都只影响自己的层级。