自托管 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自托管的 SimDocker 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_FILEdocker-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 默认库名是simstudioHelm 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 databaseCompose 文档进一步要求把它保存在服务器之外升级前先打数据库快照升级文档中的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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
自托管 sim 数据库恢复后凭据无法解密怎么排查
自托管 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自托管的 SimDocker 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_FILEdocker-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 默认库名是simstudioHelm 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 databaseCompose 文档进一步要求把它保存在服务器之外升级前先打数据库快照升级文档中的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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
