authentik 备份与恢复：先保住数据库，再补齐文件、证书与定制目录-未完纪

authentik 的备份不能只理解为复制一个容器。真正决定身份系统能否恢复到可用状态的是 PostgreSQL 数据库：用户、策略、流程和配置等持久化数据都保存在这里。数据库丢失，就意味着整套应用数据丢失。原文给出的是备份范围和恢复顺序，而不是可以原样执行的一键脚本。

恢复顺序与备份范围示意。未完纪绘制；为技术示意图，不是产品界面截图。

PostgreSQL 是恢复工作的核心

备份 PostgreSQL 时，应使用数据库原生工具，例如 pg_dump、pg_dumpall，或 PostgreSQL 的连续归档机制。具体选择取决于所需备份范围、恢复点目标和现有部署方式。原文明确要求排除 PostgreSQL 系统模板库 template0 与 template1，并尽可能把备份保存在数据库主机以外的位置。

这里列出工具名称不等于把它们互相替换：pg_dump 通常围绕单个数据库生成逻辑备份；pg_dumpall 与角色等集群范围对象相关，备份范围需要单独审视；连续归档则属于另一套恢复策略。应依据所用 PostgreSQL 版本的工具文档确定格式、权限、排除规则和恢复流程。不能仅因为命令没有报错，就认定所需数据与角色已经完整纳入备份。

恢复顺序同样重要。应先恢复 PostgreSQL，确认恢复后的数据库完整，再让 authentik 重新连接并恢复服务。对于备份归档，可以按其创建方式使用 pg_restore；对于 SQL 文本，通常使用 psql。这两类恢复路径不能只按文件扩展名猜测。

确认本次备份的数据库范围、备份时间、格式及对应版本，并在独立恢复目标中准备所需数据库环境。
按备份创建方式恢复 PostgreSQL，保持 authentik 尚未重新接入。
检查恢复完整性，核对所需的用户、策略、流程和配置是否存在。
补齐部署使用的静态目录与外部存储，之后再连接 authentik。

上述第一、三步的具体检查项目属于编者补充；原文的硬性顺序是“先恢复数据库、核验完整性，再连接 authentik”。这里没有实际恢复数据库，也没有把清单当成成功演练的证据。

按实际使用情况恢复静态目录

容器化安装通常把下列目录挂载成卷。如果部署使用了这些内容，且它们包含在备份中，就需要恢复到对应位置，才能维持原有功能。备份范围应根据存储方式决定，不能机械地认为所有数据都在容器文件系统中。

目录	用途	何时需要备份与恢复
`/data`	应用图标、流程背景、上传文件和 CSV 报表	没有使用外部 S3 存储时需要。若使用 S3，则外部存储也应备份，原文指向 AWS S3 Sync 工具。
`/certs`	文件系统中的 TLS 证书	如果功能依赖这些文件，需备份。已经导入 authentik 的证书保存在数据库中，不需要仅为这些已导入证书额外依赖此目录。
`/custom-templates`	对 authentik 用户界面的定制	修改过默认外观时需要。
`/blueprints`	蓝图文件	使用自定义蓝图时，备份是可选但推荐的。

证书的两种存储位置尤其容易混淆。数据库备份可以包含已经导入的证书，但不能替代仍依赖文件系统加载的证书文件。反过来，只复制 /certs 也不能恢复数据库中的用户、策略或流程。对外部 S3 存储同理：数据库恢复完成，并不意味着对象数据也已经恢复。

把备份文件当作敏感身份数据保护

编者补充：这些备份包含身份系统的敏感内容，应限制读取权限，采取适当的加密与独立保存方式。数据库连接凭证、对象存储凭证和证书私钥不应直接写进公开脚本、命令历史或文章示例。备份文件也不应放在可公开下载的网站目录。

如果使用 S3 Sync，需要先核对源、目标、过滤条件和删除语义。把同步当成备份时，必须考虑误删是否会同步到备份端；本文不提供带删除选项的一键操作。恢复命令会改变目标数据库，执行前应明确目标，先在隔离环境验证，并留出回退路径。这里没有运行这些工具，也没有检查任何真实部署。

版本与恢复演练

这是一份持续更新的在线文档，未在正文声明一个固定的 authentik 产品版本。请把正在使用的 authentik 版本、PostgreSQL 版本、容器挂载布局和对象存储配置一起记录进恢复说明。版本升级与恢复是相关但不同的工作：不能默认跨版本恢复后，服务就能直接启动。

原文分别提供 Docker Compose 与 Kubernetes 场景的 PostgreSQL 升级指引链接，并指向 PostgreSQL 配置参考，用于查询连接设置、TLS、副本与连接池兼容性。执行时应从官方原页进入与部署匹配的版本化文档。是否能够恢复登录、流程执行、证书使用和定制界面，需要由实际演练确认；本文仅完成文档与操作风险的静态核对。