云主机上跑本地记忆库的四个运维习惯
记忆库跑在云上，麻烦不在装，在「装完之后没人管」。七层记忆库（meow-memory，latest 0.31.0，240★，MIT）把七层数据写成工作区下的一个 SQLite 文件，零运行时依赖，装上就能用——也正因为太安静，这四个习惯不养成，出事时往往没有第二条线索。
习惯一：打开 backup.enabled，并亲手验一次轮转
backup.enabled 默认是关的。打开之后，dream 收尾会用 VACUUM INTO 做一次一致性快照，按 mtime 增量轮转到 memory.db.bak，同一份内容不会重复覆盖。这套机制有三个特点值得记住：一致性、幂等、失败静默——失败不弹错，也不刷日志。
第三条决定了你必须亲手验一次：
stat -c '%y %s' .dsh-meow/memory.db.bak
sqlite3 .dsh-meow/memory.db.bak 'pragma integrity_check;'
隔一天再跑第一条，看 mtime 是否前进；第二条返回 ok，才算这份备份能用。之后再谈备份策略才有意义，不验的备份等于没有。
如果 .bak 根本没出现，按这个顺序查：确认 backup.enabled 真的落在 profile 的配置里（不是写在注释里）、确认这个窗口真的跑完过一次 dream（空闲满 3 小时且不在峰时窗口内）、必要时敲一次 /dream 手动触发。仍然没有，就把库复制一份到别的地方再用 VACUUM INTO 试一次，先把「能不能生成一致性副本」这件事和插件解耦。
备份文件建议再往对象存储放一份。ossutil 一条命令就够，别把唯一副本和库放在同一块盘上——盘坏了，两者一起没。
习惯二：把磁盘与库体积放进监控
SQLite 是单文件，memory.db 涨得快不快，取决于 fact 与 lesson 两条链路写得多不多：事实条目是原子记录，教训条目是纠正记录，都会随会话累积；sessions/<id>.json 也在长，只是量级小。
监控两件事就够：数据盘使用率（80% 报警）与 memory.db 的周增速。前者防写满导致 SQLite 报错，后者用来判断什么时候该清理过期的 topic。云监控里给数据盘挂一条告警规则，比事后 df -h 省事得多。
具体动作可以是一周一次的 du -h .dsh-meow/memory.db，把数字记在同一张表里。库不会自己收缩，写进去的条目只有被更新状态才会变「轻」，所以曲线通常是单调向上的；连续几周增速陡增，八成是某个会话在反复写同类事实，这时候去 memory_find_similar 看一眼比盲目扩容划算。
习惯三：核对时区与峰时抑制窗口的落点
dream 的峰时抑制，README 写的是北京时间 09:00–12:00、14:00–18:00。云主机的系统时区常常是 UTC，timedatectl 一看就知道。这里要做的其实是「核对落点」，而不是「改时区」：改系统时区会连带影响日志、证书续期和其他定时任务。
可行的做法是把 dream.idleMinutes 临时调小，观察一整天的整理卡片出现在什么时间，换算成北京时间记下来。落点不合适时用 /dream 手动补一次，别急着动全局时区。
换算很简单：UTC 加 8 小时就是北京时间，上面那个窗口在 UTC 主机上对应 01:00–04:00 与 06:00–10:00。核对完之后把结论写进运维文档，比每次出事重新推一遍省事。同一份文档里顺手记下 dream.idleMinutes 的当前值和 /dream 的手动补录约定，交接时能省一轮解释。
习惯四：升级前先在快照上演练
这个包 engines.node 未声明，dsh 版本约束也未声明。README 的兼容声明写到 0.1.5，站内实装验证却跑在 0.2.1-rc.2 上——两句话不冲突，也不完全等价，意味着版本组合得自己兜。
所以升级别在生产盘上试：给数据盘打快照，用快照建一块新云盘挂到测试实例，在副本上跑安装命令，确认首轮注入、检索、dream 都正常，再切回生产。顺手把当时的 Node 版本写进运维文档，下次换机器不用重猜。同类插件的实装版本与安装形态整理在 DeepSeek Harness Hub 插件清单。
总结
这四个习惯的共同点是把「安静运行」当成风险而不是优点：备份要验、体积要量、时间要对、升级要演练；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：把记忆库放在数据盘上长期运行的人；需要向团队交代备份与恢复流程的维护者；遇到过 dream 在预期时间没触发的人。
不适合：只在本地跑几天、随时重装的使用者；不愿开数据盘、也不打算做任何监控的单机试用；指望装上就永久不用管的场景。
标签：七层记忆库、DeepSeek Harness、阿里云 ECS、备份、运维
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
