superset元数据是平台核心，必须通过pg_dump/mysqldump/直接复制sqlite文件做逻辑备份，同步备份superset_config.py和.env配置，恢复时需执行superset db upgrade和superset init，并建立含校验与保留策略的自动化脚本。
Superset 的元数据是整个平台的“大脑”，一旦损坏或丢失，仪表盘、用户权限、数据源连接等全部配置将无法自动还原。Linux 服务器上部署时，元数据默认存于 PostgreSQL/MySQL（生产）或 SQLite（开发），备份必须围绕它展开，而不是只导出几个 JSON 文件。
元数据库必须做完整逻辑备份
逻辑备份生成可读、可验证、可迁移的 SQL 文件，是恢复最可靠的基础。不能依赖 Superset 自带的 export-all 命令——它只导出部分资产（如仪表板和图表），不包含用户角色、权限规则、SQL Lab 历史、切片定义等关键元数据。
- PostgreSQL：用 pg_dump 导出全库，推荐自定义格式（-F c）便于压缩和选择性恢复
- MySQL：用 mysqldump，加上
--single-transaction --routines --triggers确保一致性 - SQLite：直接复制
superset.db文件即可，但仅限开发或低负载场景
配置文件与环境变量同步备份
光有元数据还不够。Superset 启动依赖 superset_config.py 和 .env 中的关键参数，比如 SECRET_KEY、SQLALCHEMY_DATABASE_URI、缓存配置和 LDAP 设置。这些一旦错配，即使数据库恢复成功，服务也无法启动或权限异常。
- 每次修改配置后，立即备份当前版本，并标注变更说明（例如：“20260614_ldap_enabled”）
- 建议将配置文件纳入 Git 版本管理（排除敏感字段，用占位符替代密码）
- Docker 部署时，确认
docker-compose.yml中volumes正确挂载了配置路径，避免容器重建后配置丢失
恢复流程要分步验证，不可跳过初始化
恢复不是简单替换数据库文件。Superset 对元数据表结构有严格版本要求，新旧版本间可能存在 schema 不兼容。直接导入旧 dump 可能导致启动失败或功能异常。
- 先停掉 Superset 服务（
superset run或systemctl stop superset） - 清空目标库（或新建空库），再用
psql -U user -d superset 导入 - 执行
superset db upgrade—— 这一步会校验并自动补齐缺失的 migration 表，是官方强制要求 - 最后运行
superset init重置 admin 权限，确保基础角色体系可用
自动化脚本需包含保留策略与校验环节
手动备份容易遗漏，但盲目堆砌备份文件又会耗尽磁盘。一个健壮的脚本应兼顾时效性、空间控制与可恢复性验证。
- 每天凌晨 2 点执行备份，文件名含时间戳（如
superset_db_20260615_0200.sql） - 保留最近 7 天全量备份 + 最近 30 天的周备份（每周日额外存一份）
- 每次备份后运行
head -n 20 backup.sql | grep "CREATE TABLE"，确认文件非空且结构完整 - 每月抽样一次：在测试环境拉起临时 Superset 实例，导入最新备份，验证能否登录、加载仪表盘
