Бэкап и восстановление Apache Superset

MAATRIX

Superset — мощная альтернатива Tableau с открытой лицензией, но вся эта мощь опирается на одну служебную базу: там живут подключения к десяткам источников данных, сотни датасетов, чартов и дашбордов, роли и права доступа. Потеряйте её без бэкапа — и вместо аварийного восстановления придётся заново собирать BI-платформу с нуля, пересоздавая каждое подключение и каждый чарт руками. Разберём, что именно нужно бэкапить в Superset, как это автоматизировать и как поднять инстанс на чистом сервере без сюрпризов.

Что именно нужно бэкапить в Superset

У Superset нет единого «файла проекта» — почти всё состояние живёт в реляционной metadata database. В тестовой установке это SQLite-файл, но для продакшена Superset настоятельно рекомендует внешний PostgreSQL или MySQL: SQLite не переживает параллельную запись от нескольких воркеров и обычно первым делом мигрируется при переходе от demo-стенда к боевому серверу.

В metadata database хранится: пользователи, роли и права доступа (RBAC); подключения к источникам данных с зашифрованными паролями; датасеты — физические и виртуальные (сохранённые SQL-запросы); чарты и дашборды со всей раскладкой и фильтрами; сохранённые запросы SQL Lab, CSS-темы, аннотации, тэги; расписания алертов и отчётов (Alerts & Reports).

Ключевая ловушка — думать, что бэкап Superset означает бэкап аналитических данных. Это не так: Superset хранит только *описание* того, как их визуализировать, а сами таблицы с цифрами живут в источниках и бэкапятся отдельно. Если один из источников — PostgreSQL, пригодится статья про настройку PostgreSQL на VPS.

Бэкап metadata database через pg_dump

В официальном docker-compose из репозитория apache/superset сервис Postgres обычно называется db, переменные заданы в docker/.env (POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD). Проверьте свои имена, прежде чем копировать команды один в один.

cd /opt/superset
set -a; source docker/.env; set +a

mkdir -p /opt/superset-backup/db

docker compose exec -T db pg_dump \
  -U "${POSTGRES_USER}" -Fc "${POSTGRES_DB}" \
  > /opt/superset-backup/db/superset_$(date +%F_%H%M).dump

Если metadata database вынесена на отдельный управляемый сервер — та же команда, но с -h db.internal и PGPASSWORD вместо docker compose exec.

Custom-формат (-Fc) даёт сжатие и выборочное восстановление отдельных таблиц через pg_restore --table — удобно, если после сбоя нужно вытащить только dashboards или ab_user, не поднимая всю базу целиком. На базах от нескольких гигабайт (когда в SQL Lab накопилась история запросов за годы) дамп и restore заметно ускоряет тюнинг work_mem на самом Postgres-сервере.

Если metadata database ещё на SQLite — бэкап сводится к копированию файла при остановленном контейнере, иначе есть риск снять файл в момент незавершённой записи:

docker compose stop superset
docker compose cp superset:/app/superset_home/superset.db \
  /opt/superset-backup/db/superset_$(date +%F).db
docker compose start superset

Для чего угодно серьёзнее теста переносите metadata database на PostgreSQL — миграция делается один раз через SQLALCHEMY_DATABASE_URI и superset db upgrade на новой базе, а дальше бэкап становится обычным pg_dump без даунтайма.

Экспорт ассетов через superset export-assets

Дополнительно к дампу базы у Superset есть команда export-assets — она выгружает дашборды, чарты, датасеты и описания подключений в ZIP с YAML-файлами:

docker compose exec superset superset export-assets \
  -f /app/superset_home/assets_$(date +%F).zip

docker compose cp superset:/app/superset_home/assets_$(date +%F).zip \
  /opt/superset-backup/assets/

Плюсы: YAML читаем, его удобно класть в git и смотреть diff после правок аналитика; можно выборочно переносить дашборды между dev- и prod-окружениями. Минусы: экспорт не включает пароли к источникам (по соображениям безопасности) и не переносит права доступа так же гранулярно, как полный дамп — после import-assets на новом окружении пароли придётся ввести заново. Точные флаги отличаются между версиями — сверьтесь с superset export-assets --help для своего релиза.

docker compose exec superset superset import-assets \
  -p /app/superset_home/assets_2026-08-30.zip

Разумная стратегия: pg_dump — источник истины для аварийного восстановления «в точности как было», export-assets в git — читаемая история изменений и способ переноса между окружениями без полного дампа продовой базы.

SECRET_KEY, конфиг и что бэкапить не обязательно

SECRET_KEY — самая критичная строка конфигурации. Ею Superset шифрует пароли к источникам данных прямо в metadata database и подписывает сессии и CSRF-токены. Потеряете ключ вместе с рабочим дампом базы — базу поднимете, дашборды увидите, но каждое подключение откажется работать с ошибкой расшифровки, а все пользователи разлогинятся разом.

grep SECRET_KEY /opt/superset/docker/pythonpath_dev/superset_config.py \
  >> /opt/superset-backup/config/secrets_$(date +%F).env

Храните ключ отдельно от дампа базы — в password-менеджере или зашифрованном секрет-сторе — но так же надёжно. В части актуальных версий Superset появилась поддержка ротации SECRET_KEY без потери доступа к сохранённым секретам; если такая возможность есть в вашем релизе — сверьтесь с changelog перед экспериментами в проде.

superset_config.py и .env — здесь feature flags, лимиты (ROW_LIMIT, SQL_MAX_ROW), настройки кеша, OAuth/LDAP для входа. Держите файл в приватном git-репозитории или копируйте вместе с остальным бэкапом.

Redis бэкапить не обязательно. Он используется для кеша чартов и как брокер/result-backend Celery — очереди асинхронных запросов и джобов Alerts & Reports. Кеш пересоберётся сам при первом обращении к дашборду. Расписания алертов хранятся в metadata database, а не в Redis, и переживают восстановление — но после отката базы стоит перезапустить superset-worker-beat, чтобы Celery Beat перечитал расписание, а не работал с устаревшим локальным состоянием.

Автоматизация: скрипт, ротация, шифрование, офф-сайт

#!/usr/bin/env bash
set -euo pipefail

STAMP=$(date +%F_%H%M)
DEST=/opt/superset-backup
GPG_RECIPIENT="backup@yourdomain.example"

cd /opt/superset
set -a; source docker/.env; set +a

mkdir -p "$DEST"/{db,assets,config}

# 1. дамп metadata database
docker compose exec -T db pg_dump \
  -U "${POSTGRES_USER}" -Fc "${POSTGRES_DB}" \
  > "$DEST/db/superset_${STAMP}.dump"

# 2. экспорт ассетов (дашборды, чарты, датасеты)
docker compose exec superset superset export-assets \
  -f "/app/superset_home/assets_${STAMP}.zip"
docker compose cp "superset:/app/superset_home/assets_${STAMP}.zip" "$DEST/assets/"

# 3. конфиги и SECRET_KEY
cp docker-compose.yml docker/.env "$DEST/config/"
grep SECRET_KEY docker/pythonpath_dev/superset_config.py >> "$DEST/config/secrets_${STAMP}.env"

# 4. шифруем дамп и секреты
for f in "$DEST/db/superset_${STAMP}.dump" "$DEST/config/secrets_${STAMP}.env"; do
  gpg --yes --batch --recipient "$GPG_RECIPIENT" --output "${f}.gpg" --encrypt "$f"
  rm "$f"
done

# 5. ротация — хранить 14 дней
find "$DEST/db" -name '*.gpg' -mtime +14 -delete
find "$DEST/assets" -name '*.zip' -mtime +14 -delete

# 6. синхронизация на удалённое хранилище
rclone sync "$DEST" remote:superset-backups --log-file=/var/log/superset-backup.log

Cron ежедневно ночью:

0 3 * * * /opt/superset-backup/backup.sh >> /var/log/superset-backup-cron.log 2>&1

Шифрование не для галочки: в дампе лежат хеши паролей пользователей Superset и чувствительные строки подключений. Для настройки rclone под S3-совместимое хранилище и сравнения инструментов бэкапа пригодится статья restic или BorgBackup — что выгоднее и когда.

Восстановление Superset из бэкапа

1. Поднимаем чистую инфраструктуру — Postgres и Redis, создаём пустую базу с тем же именем, что было в POSTGRES_DB: docker compose up -d db redis && docker compose exec db createdb -U "${POSTGRES_USER}" "${POSTGRES_DB}".

2. Восстанавливаем дамп (сначала расшифровав, если зашифрован):

gpg --output superset_restore.dump --decrypt superset_2026-08-30_0300.dump.gpg

docker compose exec -T db pg_restore \
  -U "${POSTGRES_USER}" -d "${POSTGRES_DB}" --clean --if-exists \
  < superset_restore.dump

Флаг --clean --if-exists безопасно очищает существующие объекты перед восстановлением — пригодится, если Superset уже успел стартовать на пустой базе и накатить системные миграции.

3. Возвращаем SECRET_KEY. Значение в новом superset_config.py должно быть точно тем же, что на старом сервере, иначе пароли к источникам не расшифруются, а сессии пользователей окажутся невалидны.

4. Прогоняем миграции и запускаем сервис:

docker compose run --rm superset superset db upgrade
docker compose run --rm superset superset init
docker compose up -d superset superset-worker superset-worker-beat

superset init идемпотентна — досоздаёт недостающие роли и права, но не трогает существующие данные, поэтому безопасна и на восстановленной базе.

5. Смотрим логи миграций, а не просто ждём «зелёного» статуса: docker compose logs -f superset | grep -i migrat. Затем открываем пару дашбордов из разных источников и пробуем отредактировать (не сохраняя) существующее подключение — если Superset не ругается на ошибку расшифровки пароля, SECRET_KEY восстановлен верно.

Регулярно проверяйте, что дамп вообще разворачивается на чистом окружении — бэкап, который ни разу не восстанавливали тестово, есть смысл считать несуществующим. Общие принципы такой проверки — в статье восстановление базы данных из бэкапа на практике.

Типичные грабли

Потеря SECRET_KEY. Самая частая и болезненная проблема: база восстановилась, Superset запустился, но каждое подключение к источнику падает с ошибкой расшифровки. Решение одно — вручную ввести пароли ко всем источникам заново.

SQLite незаметно доехал до продакшена. Стенд подняли «на попробовать» с дефолтным docker-compose, где metadata database — SQLite-файл, а через полгода на нём уже полсотни рабочих дашбордов. SQLite не годится для параллельной записи и не даёт снять консистентный снимок без остановки сервиса. Мигрируйте на PostgreSQL как можно раньше.

Несовпадение версий при восстановлении. Если образ новее того, что писал бэкап, superset db upgrade обычно накатывает миграции вперёд без проблем. Откатить схему назад штатно нельзя — миграции необратимы. Фиксируйте версию образа тегом, а не latest.

Дамп базы — не бэкап аналитических данных. Восстановив Superset, вы вернёте дашборды и запросы, но не сами цифры — если продовый ClickHouse или PostgreSQL недоступны, дашборды покажут ошибки подключения или пустые графики. Про сервер под саму аналитическую базу — статья про выделенный сервер для аналитики больших данных.

Забытый рестарт Celery Beat. Расписания Alerts & Reports хранятся в базе и переживают restore, но процесс superset-worker-beat кеширует расписание локально при старте. Не перезапустите контейнер — часть алертов может сработать по старому расписанию или пропустить срок.

Частые вопросы