企业官网建设流程全解析

自托管 sim 数据库恢复后凭据无法解密怎么排查

【免费下载链接】simSim is the collaborative workspace to build, deploy, and monitor AI agents and workflows. Used by 100,000+ builders.项目地址: https://gitcode.com/GitHub_Trending/sim16/sim

自托管的 Sim（Docker Compose 或 Kubernetes/Helm 部署）从数据库备份恢复后，应用能启动、能登录，但集成账号显示已连接、一执行就失败，或者 provider 密钥在解密时报错。官方排查文档把这一现象归因到单一根因：恢复后使用的ENCRYPTION_KEY与备份生成时正在使用的值不一致。ENCRYPTION_KEY不可恢复、不可推导，也无法通过轮换解决，唯一路径是把原始密钥放回去。本文按"确认现象 → 核对当前密钥 → 换回原始密钥 → 验证"这条路径展开，全部内容来自 Sim 的自托管文档。

现象判断：连接正常但解密失败

排查文档中 "Credentials Unreadable After a Restore" 一节给出的现象是：

Integrations show as connected but fail, or provider keys error on decrypt.ENCRYPTION_KEYdoes not match the value in use when the backup was taken.

注意区分：这不是应用或数据库的问题。架构文档明确说明，数据库恢复配上不同的密钥会得到一个"看起来正常"的应用——它能加载、能登录——但其中所有被加密的数据都解密不出来。也就是说，凭据问题往往在有人真正跑一次工作流之前都不会暴露。

ENCRYPTION_KEY加密的数据包括：workspace 与个人环境变量、已存储的 provider API 密钥、MCP OAuth 凭据、deployment/chat 密钥。它是固定形状的密钥——恰好 64 个十六进制字符（openssl rand -hex 32的输出），见 环境变量文档。

第一步：核对当前正在使用的ENCRYPTION_KEY

排查的前提是确认两件事：恢复后的应用容器里实际加载的是哪个值，以及备份生成时用的是哪个值。

Docker Compose 安装——密钥写在 Compose 文件旁的.env里。文档在 Docker 指南中要求把ENCRYPTION_KEY保存在服务器之外，恢复数据库时如果只换了数据卷而没有核对这个值，就是最常见的踩坑点。文档在检查容器是否拿到某个变量时使用exec <服务> printenv <变量>模式（排查文档用它核对VLLM_BASE_URL），用同样方式确认密钥进入了容器：

COMPOSE_FILE=docker-compose.prod.yml docker compose -f "$COMPOSE_FILE" exec simstudio printenv ENCRYPTION_KEY

输出为空说明变量根本没到达容器；输出与.env不一致说明服务还没重建。

Helm 安装——Kubernetes 文档给出找回已用值的方法：

helm get values sim -n simstudio

文档原文强调：转换或迁移已有安装时必须复用原始密钥值，如果 shell 里已经没有这些值，就用上面的命令取回。

把取到的值和"备份生成时正在使用的密钥"（你当初随数据库备份一起单独保存的那份）比对。两者不同，就是本文现象的直接原因。

第二步：换回原始密钥

排查文档对此只给出一条结论性指令：

There is no recovery — the original key must be restored.

即不存在绕过手段，只能把原始值写回配置并让应用加载它。

Docker Compose——把.env中的ENCRYPTION_KEY改回原始值，然后重建读取它的应用服务（这是文档中应用.env变更的标准命令）：

docker compose -f docker-compose.prod.yml up -d --force-recreate simstudio docker compose -f docker-compose.prod.yml exec simstudio printenv ENCRYPTION_KEY

第二条命令用来确认新值确实落进了容器。

Helm——把 release 中的ENCRYPTION_KEY值恢复为原始值（通过你的 values 或 secret），再正常执行helm upgrade。

两点边界说明：

• 不要生成新密钥来"修复"。安全文档的 FAQ 明确回答：ENCRYPTION_KEY无法在不重新加密全部数据的前提下轮换，改掉它会让上述所有数据永久不可读。
• 数据库名在两种部署中不同，后续如需执行pg_dump/psql等检查注意区分：Compose 默认库名是simstudio，Helm chart 默认是sim（见 升级文档）。

第三步：验证密钥与备份匹配

验证分两层，文档对两者的证明力有明确区分。

npx sim-setup doctor（快速形状检查）：在 Compose 安装目录运行后，它的 Schema 检查组会校验ENCRYPTION_KEY恰好是 64 位十六进制字符。但它只查形状，不证明这个值与备份匹配——一个格式正确但值不同的密钥同样会通过。

真正的验证是 验证清单的"恢复后"流程。文档要求恢复后跑完整清单，并特别点名第 5 步：

Run the whole list, and pay special attention tostep 5 with an OAuth-backed integration. That is what provesENCRYPTION_KEYmatches the backup.

第 5 步的具体操作（来自清单原文）：在设置里粘贴一个模型 API 密钥，跑一个两块的 workflow。它覆盖执行引擎、凭据加密和出站网络。判断方法同样来自文档的"Reading the failures"一节：如果报错与凭据解密有关，说明ENCRYPTION_KEY与当初加密它的密钥仍然不一致——回到第一步重新核对。

原始密钥找不回时

如果当初没有随数据库单独备份密钥，文档的立场是明确的：无法恢复，被加密的数据（workspace/个人环境变量、存储的 provider API 密钥、MCP OAuth 凭据、deployment/chat 密钥）保持不可读状态。此时唯一能做的补救是防止二次损失——恢复运行后，为新写入的数据使用一个确定可长期保管的密钥，并接受旧数据不可读。

顺带区分一个相邻概念：API_ENCRYPTION_KEY的失败模式不同——它丢失后，已生成的 API 密钥仍能继续认证，只是其存储副本不能再被显示（见 安全文档）。它不改变本文的排查结论，但排查时可以借此缩小范围：如果 API 密钥调用正常、只有集成凭据解密失败，问题就集中在ENCRYPTION_KEY。

预防措施以文档为准：ENCRYPTION_KEY必须与数据库分开备份（架构文档："Back it up separately from the database"），Compose 文档进一步要求把它保存在服务器之外；升级前先打数据库快照（升级文档中的pg_dump命令）时，把当时的密钥值一并记录在同一份备份说明里，恢复时成对使用。

参考

• Troubleshooting：现象判定与 "Credentials Unreadable After a Restore" 条目
• Verify Your Install：恢复后验证清单与失败判读
• Docker：密钥保存要求与数据库备份/恢复命令
• Security：密钥轮换与备份约束
• Upgrades：升级前备份与数据库命名差异

【免费下载链接】simSim is the collaborative workspace to build, deploy, and monitor AI agents and workflows. Used by 100,000+ builders.项目地址: https://gitcode.com/GitHub_Trending/sim16/sim