企业官网建设流程全解析

Hindsight记忆备份与灾难恢复：4步配好自动备份与恢复验证

【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight

生产环境里的智能体跑了三个月，数据库磁盘坏了——记忆库里积累数月的记忆无法一夜重建。本文按顺序讲清 Hindsight 记忆备份与恢复的完整流程：数据存在哪、自动备份怎么配、恢复后如何确认可用，以及上线前要备齐什么。

会话上下文每轮结束即清空，而 Hindsight 的记忆跨会话保留——这也是备份对象与临时上下文的根本区别。

盘点：哪些记忆存在哪里

Hindsight 把智能体记忆存在 PostgreSQL 数据库里，仓库自带的hindsight-admin管理命令直连数据库完成备份与恢复（不经过 HTTP API）。实现位于 hindsight-api-slim/hindsight_api/admin/，完整命令参考见官方 admin-cli 文档。一次备份（zip 文件）覆盖的内容：

• 记忆银行及其配置：每个 bank 对应一组相互隔离的记忆
• 文档与分块：原始输入及切块结果
• 记忆单元：事实（facts）、经验（experiences）、观察（observations）三类结构化记忆
• 实体与关系：实体共现、记忆链接
• 心智模型与指令
• Webhooks、文件存储，以及内部运维表（异步操作、审计日志、维护队列等，保证恢复后是一个完整一致的快照）

Hindsight 控制界面中的记忆面板：下拉框列出各记忆银行，主区域展示记忆图谱，这就是备份要保护的全部对象。

两个前提：备份在REPEATABLE READ事务中执行，所有表取同一时刻快照，不会出现半写状态；该工具仅支持 PostgreSQL 后端，嵌入式的 pg0 开发库需要在持有其数据的宿主机上执行。

备份：手动、自动与多租户

单机全量备份

安装hindsight-api后hindsight-admin即可用。命令与 API 服务读取同一套配置，由HINDSIGHT_API_DATABASE_URL决定操作哪个库：

# 备份默认 public schema（路径不带 .zip 会自动补上） hindsight-admin backup /backups/hindsight-2026-01-15

执行结束会打印本次备份的总行数与表数，建议记录在案，作为日后恢复核对的基线。

容器内执行备份（Docker / Kubernetes）

在 API 容器或 Pod 内执行，直接继承环境变量，不必单独配置：

docker exec -it hindsight-api hindsight-admin backup /data/backup.zip kubectl exec deploy/hindsight-api -- hindsight-admin backup /data/backup.zip

多租户备份：按 schema 隔离

多租户部署中每个租户对应独立的数据库 schema。加--schema参数即可只备份一个租户，例如hindsight-admin backup /backups/tenant-acme --schema tenant_acme，互不影响其他租户的数据。

从单一记忆银行到多租户隔离：备份与恢复都可以精确到单个 schema。

配置自动备份

每次执行都是一次全量快照，所谓自动备份就是把它交给定时任务：cron 每天低峰期跑一次即可，具体写法见下文「30分钟上手」第 4 步。

恢复：不只是还原，还要可用

⚠️风险：restore会删除目标 schema 中的全部现有数据再导入备份文件。默认交互确认，脚本可用--yes跳过。恢复前务必确认手里有可用的最新备份。

# 交互式确认（默认） hindsight-admin restore /backups/hindsight-2026-01-15.zip # 跳过确认，供脚本使用 hindsight-admin restore /backups/hindsight-2026-01-15.zip --yes

租户级恢复追加--schema tenant_acme --yes即可。

数据回库不等于恢复完成，还有两步才真正可用：

1. 修复向量索引：恢复属于逻辑恢复，bank 级的局部向量索引不会随之恢复，缺失时该库范围的检索会静默退回全局索引加过滤，既慢又可能少召回。恢复后执行一次hindsight-admin repair-bank --all，该操作幂等、可重复执行，服务在线时也不会阻塞。
2. 清理卡住的任务：若故障期间 worker 身份丢失，队列中可能残留processing状态的任务。用hindsight-admin worker-status查看，再用hindsight-admin decommission-workers把孤儿任务释放回pending。

恢复后验证清单：

• 核对记忆银行数量、记忆总行数，与备份时打印的基线一致
• 挑 2-3 个已知问题执行 recall 查询，确认召回结果符合预期
• 查看银行 stats 中pending_consolidation等计数器是否随时间正常下降

恢复完成后的记忆图谱：星座视图里应能看到记忆节点与语义、时间、实体、因果四类链接，可用作肉眼核验。

生产化：策略、监控与演练

备份策略取决于写入量，每次都是全量快照，参考配置：

存储位置：近期备份留本地磁盘以便快速恢复，同时同步一份到对象存储或异地主机，避免「库和备份在同一块盘上」这种单点。

监控点建议盯四个：

• 成败与行数：备份脚本退出码，以及Backed up N rows输出，行数骤变通常是最早的异常信号
• 文件大小：zip 体积持续变小要查原因
• 恢复测试：每月用测试环境实际恢复一次最新备份，走完整验证流程
• 存储水位：备份目录与对象存储的容量余量

演练流程：每月固定一次——临时环境恢复最新备份 → 执行上一节的验证清单 → 记录实际耗时与卡点 → 归档结果。演练的意义不是证明「能恢复」，而是知道要多久、哪里会卡。

另外，跨版本或跨环境迁移单个银行（更换嵌入模型、向量扩展）有专门路径：hindsight-admin export-bank/import-bank，不携带向量，由目标实例用自身模型重新嵌入，适合蓝绿切换场景。

30分钟上手

最短可用路径四步：

1. 安装工具：pip install hindsight-api，确认可执行hindsight-admin --help
2. 配置连接：export HINDSIGHT_API_DATABASE_URL=postgresql://user:pass@localhost:5432/hindsight
3. 打第一份备份：hindsight-admin backup /backups/hindsight-first
4. 加入定时任务，每天低峰全量：

# 每天 03:00 全量备份（覆盖式保留最近一份） 0 3 * * * hindsight-admin backup /backups/hindsight-daily

上线前自检清单

• 至少一份成功备份文件，且记录了行数与文件大小的基线
• 恢复流程在测试环境实际走过一遍，包含repair-bank与召回验证
• 备份文件存放在与数据库宿主机不同的位置（对象存储或异地）
• 定时备份已生效，失败时能通过日志或通知被发现
• HINDSIGHT_API_WORKER_ID设为稳定值，避免恢复后任务变成孤儿

备份成为例行动作、恢复路径被实际验证过，记忆库才算真正上了保险。

【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight