与Obsidian同步的博客搭建（六）——持续运维

网站上线后，真正花时间的不是第一次部署，而是持续区分“内容变化”“代码变化”“配置变化”和“互动数据变化”。四类变化采用不同备份与回滚路径，避免一个小改动演变成整站重建。

内容更新流程

1. 在 Obsidian 编辑 Blog、Wiki、Project 或 Daily。
2. 使用 Bedic Publisher 明确发布或更新修订。
3. 等待 Obsidian Sync 完成。
4. Headless Sync 把变化写入 Server Mirror，并产生队列事件。
5. Publisher 构建候选；没有公开修订变化时返回 noop。
6. 候选通过后原子激活，旧 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，公开版本始终可追踪，动态互动始终独立，任何失败都只影响自己的层级。

上一篇：与Obsidian同步的博客搭建（五）——服务器部署
返回系列：与Obsidian同步的博客搭建（一）——前言