记录可恢复基线
变更服务前，记录源码提交或镜像标签、数据库驱动、数据位置、附件存储和外部地址。秘密信息应单独保存。架构指南说明哪些组件位于同一进程，哪些外部服务需要独立管理。
# Native installation: inspect the built artifact
./build/memos --version
# Local container example: inspect status and recent logs
docker inspect memos --format '{{.State.Status}}'
docker logs --tail 100 memos
curl --fail http://127.0.0.1:5230/healthz维护简短运维检查表
检查频率应符合自己的部署情况，应用不会自动替你完成这些运维任务。有效检查应留下可验证结果，例如恢复后的测试笔记或可下载的测试附件，而不只是仪表盘上的绿色状态。
- 确认健康状态、可用磁盘空间和近期启动错误
- 检查备份是否完成，并定期恢复到隔离副本
- 通过外部地址验证登录、已保存笔记和附件
- 检查失败的出站集成以及过期或不再需要的访问
- 升级前记录上次验证过的回退产物
先定位失败层
从最小的失败操作开始定位。故障排查提供更完整的调查步骤；不要为了诊断而关闭访问控制或删除数据目录。
| 症状 | 优先检查 |
|---|---|
| 进程无法启动 | 配置语法、端口冲突、数据库连接、目录权限 |
| 健康检查成功但网页不可用 | 嵌入的前端构建、外部地址、反向代理 |
| 登录失败 | 时钟、HTTPS/Cookie、身份提供方回调及账号状态 |
| 文件丢失 | 存储目标、对象是否存在、应用授权 |
| 请求缓慢 | 数据库、出站提供方、上传大小与各层耗时 |
区分备份、导出与回退
个人笔记导出不是完整服务器备份。恢复实例可能需要同一一致时点的数据库、本地或远程附件文件，以及部署配置。旧二进制也未必能理解升级后的数据库。执行升级与回退前先落实备份与恢复，并用合成记录验证恢复或升级后的实例。