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

MAATRIX

Redash хранит сотни запросов, дашборды, которые смотрит вся команда, и подключения к десятку баз данных с их учётными данными — но большинство инсталляций бэкапят только контейнер с приложением, забывая про PostgreSQL-базу метаданных и секретный ключ, без которого сохранённые пароли к источникам данных превращаются в нечитаемый мусор. Ниже — рабочая схема бэкапа Redash: что действительно нужно сохранять, как автоматизировать это через cron, и как восстановить инстанс на новом сервере так, чтобы дашборды и подключения к базам поднялись сразу, без ручного пересоздания каждого data source.

Что на самом деле нужно бэкапить в Redash

Redash — это не монолит, а связка из нескольких сервисов, и потерять можно каждый по-своему:

• PostgreSQL-база метаданных Redash (обычно называется postgres в docker-compose, база postgres внутри) — здесь лежит абсолютно всё: пользователи, группы, запросы, версии запросов, дашборды, виджеты, алерты, расписания обновлений и, главное, таблица data_sources с зашифрованными строками подключения к вашим рабочим базам (хост, логин, пароль).
• Секретный ключ REDASH_COOKIE_SECRET (в свежих версиях также REDASH_SECRET_KEY) — этим ключом Redash шифрует поле options в data_sources. Восстановили базу на новом сервере с другим ключом — и все источники данных в интерфейсе будут выдавать ошибку подключения, пока вы вручную не введёте пароли заново. Для инсталляции с полусотней источников это несколько часов работы руками.
• Redis — очередь задач (Celery/RQ) и кэш последних результатов запросов. Бэкапить не обязательно: очередь эфемерна, а кэш результатов пересоберётся сам при следующем запуске запросов. Единственное, что теряется при потере Redis без бэкапа, — это последние закэшированные результаты, которые всё равно устареют.
• docker-compose.yml и .env (или env файл) — версия образа redash/redash, порты, параметры воркеров (WORKERS_COUNT), настройки почты для алертов, REDASH_HOST. Без этого файла новый сервер придётся конфигурировать с нуля, вспоминая, что где было прописано.
• Дополнительные визуализации и query snippets, если вы их кастомизировали, — они тоже сидят в базе метаданных, отдельно бэкапить не нужно.

Проверьте, какая у вас версия развёртывания:

docker compose ps
# или старый docker-compose
docker-compose ps

Если сервисы называются redash_postgres, redash_redis, redash_server, redash_worker, redash_scheduler, redash_nginx — это стандартная схема из официального docker-compose.production.yml, и всё ниже применимо напрямую.

Бэкап базы метаданных PostgreSQL

Это ядро бэкапа. Делаем логический дамп через pg_dump внутри контейнера, чтобы не тащить на хост клиент нужной версии PostgreSQL:

mkdir -p /opt/redash-backup
docker exec redash_postgres_1 pg_dump -U postgres -Fc postgres > /opt/redash-backup/redash-db-$(date +%F).dump

Флаг -Fc — custom-формат pg_dump: он сжат по умолчанию и восстанавливается через pg_restore с возможностью параллелизма и выборочного восстановления таблиц, в отличие от plain SQL. Проверить, что дамп не пустой и не битый:

ls -lh /opt/redash-backup/redash-db-*.dump
pg_restore --list /opt/redash-backup/redash-db-2026-08-30.dump | head -20

Если pg_restore --list выдаёт список объектов базы (таблицы queries, dashboards, data_sources, users и т.д.) — дамп рабочий. Пустой вывод или ошибка unrecognized file format значит, что pg_dump упал молча — проверьте логи контейнера и свободное место на диске.

Для больших инсталляций (десятки тысяч сохранённых query results) можно исключить таблицу query_results из регулярного бэкапа — это кэш результатов, он растёт быстрее всего и не критичен для восстановления работоспособности:

docker exec redash_postgres_1 pg_dump -U postgres -Fc \
  --exclude-table-data='query_results' \
  postgres > /opt/redash-backup/redash-db-light-$(date +%F).dump

Это резко уменьшает размер бэкапа, но при восстановлении графики на дашбордах будут пустыми до первого обновления запроса — учитывайте этот компромисс сами, в зависимости от того, насколько критичны исторические результаты именно для вас.

Бэкап секретного ключа и конфигурации

Ключ и переменные окружения обычно лежат в env (или .env) рядом с docker-compose.yml. Найдите его:

cd /opt/redash
grep -E 'REDASH_COOKIE_SECRET|REDASH_SECRET_KEY|POSTGRES_PASSWORD' env

Скопируйте этот файл в архив бэкапа вместе с самим compose-файлом:

cp env docker-compose.yml /opt/redash-backup/config-$(date +%F)/

Если ключа в env нет вообще (старые инсталляции иногда генерировали его на лету при первом запуске и не сохраняли явно) — зафиксируйте его сейчас, пока он ещё жив в переменных окружения работающего контейнера:

docker exec redash_server_1 env | grep -E 'SECRET|COOKIE'

Впишите найденное значение явно в env-файл и перезапустите стек, чтобы ключ не зависел от того, пересоздаст ли Docker контейнер с тем же случайным значением при следующем поднятии — он не пересоздаст, и это главная причина, почему после «просто передеплоя» источники данных внезапно перестают коннектиться.

Автоматизация бэкапа: скрипт и cron

Собираем всё в один скрипт, который берёт дамп базы, конфиг и сжимает в один архив с датой:

cat > /opt/redash-backup/backup-redash.sh << 'EOF'
#!/bin/bash
set -euo pipefail

BACKUP_DIR=/opt/redash-backup
DATE=$(date +%F)
STACK_DIR=/opt/redash
RETENTION_DAYS=14

mkdir -p "$BACKUP_DIR/$DATE"

docker exec redash_postgres_1 pg_dump -U postgres -Fc postgres \
  > "$BACKUP_DIR/$DATE/redash-db.dump"

cp "$STACK_DIR/env" "$STACK_DIR/docker-compose.yml" "$BACKUP_DIR/$DATE/"

tar -czf "$BACKUP_DIR/redash-backup-$DATE.tar.gz" -C "$BACKUP_DIR" "$DATE"
rm -rf "$BACKUP_DIR/$DATE"

find "$BACKUP_DIR" -name 'redash-backup-*.tar.gz' -mtime +$RETENTION_DAYS -delete

echo "$(date): backup redash-backup-$DATE.tar.gz done, size $(du -h "$BACKUP_DIR/redash-backup-$DATE.tar.gz" | cut -f1)"
EOF
chmod +x /opt/redash-backup/backup-redash.sh

Проверьте вручную, что скрипт отрабатывает без ошибок, и только потом ставьте в cron:

/opt/redash-backup/backup-redash.sh

Добавьте в cron ежедневный запуск ночью, когда нагрузка на источники данных минимальна:

crontab -e

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

Раз в месяц полезно смотреть в /var/log/redash-backup.log, что задача действительно отрабатывает, а не падает молча из-за забитого диска — это частая причина, по которой «бэкапы вроде настроены», а на деле последний рабочий архив датирован тремя месяцами назад.

Хранение бэкапов вне сервера

Локальный архив на том же диске защищает от человеческой ошибки («уронили таблицу руками»), но не от отказа диска или самого сервера. Копируйте архив на отдельное хранилище — свой второй сервер, S3-совместимое хранилище или выделенный сервер под бэкапы.

Через rclone (настройте remote заранее командой rclone config):

rclone copy /opt/redash-backup/redash-backup-$(date +%F).tar.gz remote:redash-backups/

Добавьте эту строку в конец скрипта backup-redash.sh, чтобы выгрузка происходила автоматически после каждого локального бэкапа. Если храните архив в облаке, шифруйте его — внутри лежит env-файл с паролями к рабочим базам данных:

gpg --symmetric --cipher-algo AES256 -o redash-backup-$(date +%F).tar.gz.gpg redash-backup-$(date +%F).tar.gz

Для инфраструктуры, где важна изоляция от основного сервера, разумно держать бэкапы на отдельной машине — например, взять под архивы отдельный VPS с диском под хранилище, не связанный с продакшн-окружением напрямую.

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

Разворачивание на новом сервере — по сути, обратная операция. Сначала поднимите чистый стек Redash тем же compose-файлом, но не запускайте инициализацию базы (docker compose run --rm server create_db) — вы восстановите базу из дампа, инициализация не нужна.

mkdir -p /opt/redash && cd /opt/redash
tar -xzf redash-backup-2026-08-30.tar.gz -C /opt/redash-restore

cp /opt/redash-restore/2026-08-30/env /opt/redash-restore/2026-08-30/docker-compose.yml /opt/redash/

docker compose up -d postgres redis

Дождитесь, пока PostgreSQL полностью стартует, и восстановите дамп:

docker compose exec -T postgres pg_restore -U postgres -d postgres --clean --if-exists \
  < /opt/redash-restore/2026-08-30/redash-db.dump

Флаги --clean --if-exists заставляют pg_restore сначала снести существующие объекты (если база не пустая) перед восстановлением — без них при повторном восстановлении в уже инициализированную базу посыплются ошибки о дублирующихся таблицах. Если база создаётся с нуля и точно пустая, флаги не обязательны, но лишними не будут.

После восстановления базы поднимите остальные сервисы:

docker compose up -d
docker compose ps

Откройте веб-интерфейс и проверьте: список источников данных должен отображаться с реальными хостами (а не пустыми полями), а тестовое выполнение любого сохранённого запроса — отрабатывать без ошибки авторизации к источнику. Если подключения к источникам данных отваливаются с ошибкой расшифровки — значит, REDASH_COOKIE_SECRET в восстановленном env не совпадает с тем, которым база была зашифрована на момент дампа: сверьте значение построчно, опечатка здесь не прощает.

Отдельно проверьте очередь задач — на новом сервере Celery-воркер иногда не подхватывает расписания обновления запросов сразу после restore:

docker compose logs -f scheduler

Если в логе видно регулярные записи о постановке задач в очередь — планировщик работает, дашборды будут обновляться по расписанию как раньше.

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