如何备份自托管 sim 的 ENCRYPTION_KEY 等密钥避免数据永久不可读

如何备份自托管 sim 的 ENCRYPTION_KEY 等密钥避免数据永久不可读【免费下载链接】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如果你用 Docker Compose 或 Kubernetes 自托管了 Simsimstudio 工作区有一组密钥一旦丢失数据库再怎么恢复也救不回来ENCRYPTION_KEY加密了工作区/个人环境变量、存储的 provider API key、MCP OAuth 凭据和 deployment/chat secretsAPI_ENCRYPTION_KEY加密用户自建的 Sim API key。两者都无法重新生成或找回——Docker 部署文档的原文是用不同的 key 去恢复数据库会得到一个能启动但受保护数据永久不可读的应用。这篇文章讲三件事在你的部署里找到这些密钥、把它们存到服务器之外、以及连数据库一起备份并在恢复后验证密钥与备份能配对。这两个密钥为什么不能换、不能丢Security 文档给出五个密钥的可轮换性对比密钥保护对象能否轮换BETTER_AUTH_SECRET会话 token可以——会使所有会话失效ENCRYPTION_KEY工作区环境变量、存储的 provider key、MCP OAuth 凭据、deployment/chat secrets不行API_ENCRYPTION_KEY用户自建 API key 的可逆存储副本不行——换掉后旧 key 仍可认证但存储副本无法再显示INTERNAL_API_SECRET服务间调用可以——app 和 realtime 一起换CRON_SECRET后台任务端点可以——app 和 cron 一起换ENCRYPTION_KEY既不能在不重新加密数据的前提下轮换丢失后也无法恢复。Architecture 文档的表述更直接它不可恢复、不可推导要求单独于数据库之外备份且never rotate it casually。所以备份策略和另外三个可轮换密钥不同那三个可以在泄露时重新生成这两个只能靠备份。另外注意API_ENCRYPTION_KEY的失败方式是静默的不设置它Sim 会把用户自建 API key 以明文存入数据库只记一条警告。它是可选项但 Kubernetes 文档建议安装时就设置必须是 64 位 hex 字符串正好是openssl rand -hex 32的输出并按与ENCRYPTION_KEY同样的方式备份。两个加密 key 的格式都是恰好 64 个 hex 字符32 字节。Environment Variables 文档指出格式错误的值不会在启动时报错而是在 Sim 第一次加密或解密时才抛异常。先找到密钥不同部署方式下它们在哪里备份的前提是先能拿到当前正在使用的值而不是重新生成一个——新值对已有数据毫无意义。Docker Compose 安装密钥存放在 Compose 文件旁边的.env里npx sim-setup会生成这个文件。安装时文档给出的生成方式ENCRYPTION_KEY$(openssl rand -hex 32) API_ENCRYPTION_KEY$(openssl rand -hex 32)打开.env找到ENCRYPTION_KEY和API_ENCRYPTION_KEY两行值就是当前正在加密数据的密钥。npx sim-setup doctor会按恰好 64 个 hex 字符校验ENCRYPTION_KEY的形状可以作为值的完整性快检它从存放.env和 Compose 文件的目录运行。Kubernetes / Helm 安装Kubernetes 文档的安装流程通过--set app.env.ENCRYPTION_KEY...传入六个值。如果 shell 里已经没有当时生成的变量用这条命令找回helm get values sim -n simstudio文档特别警告了这个场景把现有部署转换到云厂商 values 文件时必须复用原始密钥值——重新生成一个ENCRYPTION_KEY会让所有此前加密的值工作区环境变量、存储的 provider key、MCP OAuth 凭据无法解密。在 Kubernetes 上Security 文档按生产就绪程度给出三档存储方式--set命令行仅开发用值会出现在helm get values和 shell 历史里、预创建的 Kubernetes Secret、External Secrets Operator推荐从 Vault / AWS Secrets Manager / Azure Key Vault / GCP Secret Manager 同步。使用预创建 Secret 时设置app: secrets: existingSecret: enabled: trueSecret 必须使用标准 key 名BETTER_AUTH_SECRET、ENCRYPTION_KEY、INTERNAL_API_SECRET、API_ENCRYPTION_KEY、CRON_SECRET等因为它是整体被消费的不支持 key 重命名。把密钥存到服务器之外Docker 文档的要求是把ENCRYPTION_KEY和API_ENCRYPTION_KEY保存到这台服务器之外的地方。Kubernetes 文档在生成六个值之后紧接着要求在继续之前把它们存到一个持久位置。Security 文档的上线前检查清单把这条列为必选项All five secrets generated fresh, stored in a secret manager, andENCRYPTION_KEY backed up separately。落到操作上就是从.envCompose或helm get valuesHelm读出ENCRYPTION_KEY和API_ENCRYPTION_KEY的当前值存入你的 secret manager 或任何位于本服务器之外的持久存储Kubernetes 部署即上文第 2、3 档方案条目名保持ENCRYPTION_KEY/API_ENCRYPTION_KEY并记下它属于哪个实例和哪份数据库备份确认备份位置本身不可被这台服务器的磁盘故障、镜像漂移或helm uninstall波及。这里文档没有指定某个具体的备份工具存到服务器之外 / secret manager是文档原文的要求具体介质由你按上面三档方案选择。备份时不要顺手重新生成一个更安全的值——生成新值openssl rand -hex 32只发生在首次安装之后这个值就是永久值。密钥要和数据库备份成对保存单独备份密钥不够恢复时必须这份 key 当时用这份 key 写过的数据库同时在场。数据库侧的备份命令文档是明确给出的Docker ComposeDocker 文档的 FAQ 原文命令# 备份。-T 必须加——不加时 exec 会分配 TTY把重定向的 dump 文件弄坏 docker compose -f docker-compose.prod.yml exec -T db pg_dump -U postgres simstudio backup.sql # 恢复 docker compose -f docker-compose.prod.yml exec -T db psql -U postgres simstudio backup.sql数据库数据持久化在名为postgres_data的 Docker volume 中。注意 Compose 的数据库名是simstudioHelm 打包的 PostgreSQL 默认库名是sim云厂商示例 values 会改回simstudio见 Upgrades 文档# Helm 打包的 Postgres kubectl exec -n simstudio statefulset/sim-postgresql -- \ pg_dump -U postgres -Fc sim pre-upgrade-$(date %F).dumpArchitecture 文档给出的 Postgres 备份路线是pg_dump/ 托管快照 PITR如果你用的是托管数据库如 AWS RDS可以用快照aws rds create-db-snapshot --db-instance-identifier sim-db \ --db-snapshot-identifier sim-pre-upgrade-$(date %Y%m%d)把密钥备份和数据库备份放在不同的位置Security 文档的backed up separately指的就是密钥单独于数据库备份但记录清楚哪份 key 对应哪份 dump——恢复时错配就是下一节描述的失败模式。恢复后如何验证密钥与备份配对Verify 文档专门有After a restore一节跑完整的验证清单并特别留意第 5 步配合 OAuth 型集成——Paste a model API key in settings and run a two-block workflow这一步验证执行引擎、凭据加密和出站网络是能证明ENCRYPTION_KEY与备份匹配的实际检验。文档的原话是一个能加载、能登录但解不开凭据的应用在有人真正跑一个 workflow 之前看起来都完全健康。恢复后建议同时跑基础设施检查# Docker Compose docker compose -f docker-compose.prod.yml ps docker compose -f docker-compose.prod.yml logs migrations curl -fsS http://localhost:3000/api/health如果恢复后看到 Troubleshooting 文档描述的Credential Unreadable After a Restore现象——集成显示已连接但调用失败或 provider key 在解密时报错——结论只有一个当前使用的ENCRYPTION_KEY与备份制作时的值不一致没有补救路径只能找回原始 key。Verify 清单第 5 步的失败判断也指向同一处如果错误与解密凭据相关说明ENCRYPTION_KEY与当初加密它的不是同一个。限制与常见错误不要轮换这两个 key。FAQ 原文Treat it as a permanent, backed-up value rather than a rotating secret. 换值等价于把受保护数据全部作废。不要在重部署时重新生成。Compose 重新up、Helm 转换云 values 时都要用.env/helm get values sim -n simstudio里查到的原值。格式错误是延迟爆炸。ENCRYPTION_KEY形状不对不会阻止启动第一次加解密才抛异常sim-setup doctor的 Schema 组会校验它恰好 64 个 hex 字符。API_ENCRYPTION_KEY未设置不等于安全。未设置时自建 API key 以明文入库且只有日志里一条警告。Security 检查清单还要求Backups configuredand a restore rehearsed——备份命令写进计划不算完成跑过一次恢复演练才算。【免费下载链接】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），仅供参考