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

MAATRIX

Authentik быстро становится единой точкой входа: через него заходят в VPN, внутренние панели, Grafana, GitLab — всё, что успели подключить по OAuth или SAML. Проблема в том, что когда падает не рядовой сервис, а сам SSO, встаёт разом весь периметр. Разберём, что конкретно нужно бэкапить в Authentik, как это автоматизировать без магии и как восстановить рабочий инстанс на чистом сервере, не потеряв пользователей и flow.

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

Authentik в типичной установке (docker-compose с официального репозитория) состоит из четырёх частей, и не все они одинаково важны для бэкапа.

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

Redis в дефолтной конфигурации Authentik бэкапить не нужно — он используется как кэш и брокер задач, а не как источник истины. После восстановления он просто соберётся заново из PostgreSQL.

Бэкап PostgreSQL — основа всего

Вся содержательная часть Authentik живёт в базе. Самый надёжный способ — дамп через pg_dump в custom-формате, он компактнее plain SQL и поддерживает параллельное восстановление.

Возьмите переменные из .env вашего стека (обычно это PG_USER, PG_PASS, PG_DB) и снимите дамп прямо из контейнера:

cd /opt/authentik
set -a; source .env; set +a

docker compose exec -T postgresql pg_dump \
  -U "${PG_USER}" -Fc "${PG_DB}" \
  > /opt/authentik-backup/db/authentik_$(date +%F_%H%M).dump

Формат -Fc (custom) удобен тем, что его можно восстановить частично или в несколько потоков через pg_restore -j. Если хотите human-readable дамп для быстрого grep по содержимому — сохраните дополнительно plain-версию с -Fp, но это скорее для отладки, а не для регулярного бэкапа.

Проверяйте, что дамп не пустой и не оборвался:

test -s /opt/authentik-backup/db/authentik_$(date +%F_%H%M).dump || echo "BACKUP FAILED" >&2

Пустой файл или код возврата не 0 — сигнал остановиться и разбираться, а не молча продолжать ротацию поверх рабочего архива.

Бэкап media, certs и конфигурации

Volume'ы с файлами бэкапятся проще всего через временный контейнер, который монтирует volume и упаковывает его в tar — так не нужно останавливать сами сервисы Authentik.

for VOL in authentik_media authentik_certs; do
  docker run --rm \
    -v ${VOL}:/data:ro \
    -v /opt/authentik-backup/volumes:/backup \
    busybox tar czf /backup/${VOL}_$(date +%F).tar.gz -C /data .
done

Рядом же копируйте конфигурацию — она маленькая, но без неё восстановление превращается в угадывание:

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

Если вы используете declarative blueprints (YAML-файлы с flow и policy, которые Authentik подхватывает на старте) — это плюс, а не замена бэкапа БД. Blueprints удобно хранить в git отдельным репозиторием, но фактическое состояние (кто в какой группе, кто когда логинился, привязанные MFA-устройства) всё равно живёт только в PostgreSQL.

Скрипт автоматического бэкапа и ротация

Собираем всё в один скрипт, который снимает дамп, архивирует volume'ы, чистит старые копии и (по желанию) отправляет свежий бэкап за пределы сервера. Отправка обязательна, если сервер, на котором крутится Authentik, — единственная копия: локальный бэкап на том же диске не спасёт при потере сервера целиком.

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

BACKUP_DIR=/opt/authentik-backup
DATE=$(date +%F_%H%M)
KEEP_DAYS=14

cd /opt/authentik
set -a; source .env; set +a

mkdir -p "${BACKUP_DIR}"/{db,volumes,config}

docker compose exec -T postgresql pg_dump -U "${PG_USER}" -Fc "${PG_DB}" \
  > "${BACKUP_DIR}/db/authentik_${DATE}.dump"

for VOL in authentik_media authentik_certs; do
  docker run --rm -v ${VOL}:/data:ro -v "${BACKUP_DIR}/volumes":/backup \
    busybox tar czf /backup/${VOL}_${DATE}.tar.gz -C /data .
done

cp .env "${BACKUP_DIR}/config/env_${DATE}"
cp docker-compose.yml "${BACKUP_DIR}/config/compose_${DATE}.yml"

# ротация локальных копий
find "${BACKUP_DIR}" -type f -mtime +${KEEP_DAYS} -delete

# отправка офсайт через restic (пример репозитория на S3-совместимом хранилище)
# restic -r s3:https://s3.example.com/authentik-backups backup "${BACKUP_DIR}"

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

Ставим в cron под root или пользователем, у которого есть доступ к docker-сокету:

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

Бэкапы содержат хэши паролей и client secrets от OAuth-приложений — храните каталог с ограниченными правами (chmod 700) и обязательно шифруйте, если копия уходит на внешнее хранилище.

Восстановление на новом сервере

Сценарий: старый сервер недоступен, у вас есть последний дамп БД, архивы volume'ов и .env. Разворачиваем с нуля.

1. Поднимите docker и docker compose, скопируйте конфигурацию:

mkdir -p /opt/authentik && cd /opt/authentik
cp /path/to/backup/config/compose_LATEST.yml docker-compose.yml
cp /path/to/backup/config/env_LATEST .env

Важно: .env должен быть именно тем, что был в бэкапе, включая AUTHENTIK_SECRET_KEY — не генерируйте новый.

2. Создайте volume'ы и восстановите в них файлы:

docker volume create authentik_media
docker volume create authentik_certs

for VOL in authentik_media authentik_certs; do
  docker run --rm -v ${VOL}:/data \
    -v /path/to/backup/volumes:/backup \
    busybox sh -c "tar xzf /backup/${VOL}_LATEST.tar.gz -C /data"
done

3. Поднимите только postgresql и redis, дождитесь готовности:

docker compose up -d postgresql redis
docker compose logs -f postgresql   # ждём "database system is ready"

4. Восстановите дамп базы:

set -a; source .env; set +a

docker compose exec -T postgresql pg_restore \
  -U "${PG_USER}" -d "${PG_DB}" --clean --if-exists \
  < /path/to/backup/db/authentik_LATEST.dump

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

5. Поднимите остальной стек и проверьте:

docker compose up -d
docker compose logs -f server worker

Зайдите в веб-интерфейс, проверьте, что видны прежние applications, provider'ы и группы пользователей. Если используете обратный прокси (Traefik как reverse proxy для докера — частый выбор перед Authentik), убедитесь, что DNS и сертификаты для домена SSO указывают на новый сервер, иначе интерфейс поднимется, но клиенты продолжат стучаться в старый IP.

Проверка бэкапов и типичные ошибки

Бэкап, который ни разу не восстанавливали, — это файл неизвестного качества, а не защита. Раз в месяц-два стоит поднимать тестовый стек в изолированной docker-сети (или на отдельной VM) и восстанавливать туда последнюю копию — это единственный способ узнать заранее, что дамп битый, а не в момент реального инцидента.

Частые ошибки, которые встречаются на практике:

• Бэкап снят во время активной миграции схемы (сразу после docker compose pull и рестарта на новую версию) — дамп может оказаться в промежуточном состоянии. Снимайте дамп до апгрейда, а не одновременно с ним.
• Потерян AUTHENTIK_SECRET_KEY — сам по себе он не блокирует восстановление данных, но без него на новом сервере не совпадут подписи сессий и части внутренних токенов, и всем пользователям придётся заново проходить логин и, возможно, перепривязывать MFA.
• Бэкапится только media, но не certs — на первый взгляд не критично, но если в Authentik загружены собственные сертификаты для SAML-провайдеров, после восстановления придётся перевыпускать их вручную и обновлять доверие на стороне SP.
• Дамп лежит там же, где и сам сервер — при потере VPS теряется и бэкап. Если для баз данных вы уже настраивали автоматизацию, взгляните на общий подход в статье про бэкап и восстановление БД из бэкапа на практике — офсайт-копия обязательна, а не опция.
• Отсутствие мониторинга самого факта бэкапа — cron может молча перестать отрабатывать (кончилось место на диске, поменялся пароль к БД). Добавьте простую проверку возраста последнего файла в мониторинг или хотя бы получайте письмо при ошибке в cron.

Если Authentik уже падает или тормозит на текущем сервере до всякого восстановления — вероятно, дело не в бэкапах, а в ресурсах: см. отдельный разбор частых ошибок Authentik на сервере и то, сколько RAM реально нужно Authentik под вашу нагрузку.

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