Перейти к содержанию

Backup и restore n8n: PostgreSQL, credentials, workflows, файлы и проверка восстановления

Обновлено: 2026-05-29

Открыть мой план

Бэкап n8n — это не один файл с workflow. Для нормального восстановления нужны база данных, encryption key, volume с настройками, binary data, список переменных окружения и понимание, какие внешние сервисы отправляют webhook на этот экземпляр. Если сохранить только JSON workflow, вы восстановите схему автоматизаций, но потеряете credentials, executions, настройки пользователей и часть состояния.

Эта инструкция нужна для self-hosted n8n на Docker Compose, Portainer или VPS. Она не обещает “волшебный бэкап в одну кнопку”: задача — собрать воспроизводимый процесс, который можно прогнать на чистом сервере и понять, что восстановление действительно сработает.

Что входит в полноценный backup n8n

КомпонентЗачем нуженКак сохранять
PostgreSQLworkflows, credentials metadata, executions, users, settingspg_dump или managed backup провайдера
N8N_ENCRYPTION_KEYрасшифровка credentialsсекретное хранилище, password manager, Vault
/home/node/.n8nлокальные настройки и иногда binary databackup volume или bind mount
Binary dataфайлы из executions, вложения, документыvolume, S3/MinIO или external storage
docker-compose.yml и .envвоспроизведение инфраструктурыGit/private repo + копия секретов отдельно
Workflow JSON exportбыстрый аудит и перенос отдельных процессовUI export или CLI export

Самый опасный пропуск — потеря N8N_ENCRYPTION_KEY. Без него база может восстановиться, но credentials станут бесполезными: n8n не сможет расшифровать токены и пароли.

Рекомендуемая структура папок 

/opt/n8n/
  docker-compose.yml
  .env
  backups/
    postgres/
    workflows/
    binary-data/
  scripts/
    backup.sh
    restore-postgres.sh
    restore-drill.sh

Секреты не храните в публичном Git. Если compose лежит в репозитории, .env должен быть закрыт, а в Git — только .env.example с названиями переменных.

PostgreSQL backup через Docker Compose 

#!/usr/bin/env bash
set -euo pipefail
cd /opt/n8n
mkdir -p backups/postgres
TS=$(date +%Y-%m-%d_%H-%M-%S)

docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -d "$POSTGRES_DB" \
  --format=custom \
  --file=/tmp/n8n_${TS}.dump

docker compose cp postgres:/tmp/n8n_${TS}.dump backups/postgres/n8n_${TS}.dump
docker compose exec -T postgres rm /tmp/n8n_${TS}.dump

find backups/postgres -type f -name '*.dump' -mtime +14 -delete
printf 'Backup saved: backups/postgres/n8n_%s.dump\n' "$TS"

Для небольшого проекта можно хранить 14–30 ежедневных дампов. Для бизнеса лучше добавить внешнее хранилище: S3/MinIO, Яндекс Object Storage, Backblaze B2 или backup-сервис провайдера VPS.

Workflow export как дополнительная страховка

CLI export не заменяет backup базы, но помогает быстро увидеть, какие workflow были на инстансе, перенести один процесс или сравнить изменения после релиза.

mkdir -p backups/workflows
TS=$(date +%Y-%m-%d_%H-%M-%S)
docker compose exec -u node -T n8n n8n export:workflow --all --output=/tmp/workflows_${TS}.json
docker compose cp n8n:/tmp/workflows_${TS}.json backups/workflows/workflows_${TS}.json

Credentials так переносить небезопасно. В production лучше восстанавливать credentials из базы и проверять, что encryption key совпадает.

Restore PostgreSQL на чистом окружении

  1. Остановите n8n и worker, чтобы они не писали в базу во время восстановления.
  2. Поднимите PostgreSQL и Redis.
  3. Создайте пустую базу или удалите старую, если это тестовый стенд.
  4. Восстановите dump через pg_restore.
  5. Запустите n8n с тем же N8N_ENCRYPTION_KEY.
cd /opt/n8n
docker compose stop n8n n8n-worker
cat backups/postgres/n8n_2026-05-29_030000.dump | docker compose exec -T postgres \
  pg_restore -U "$POSTGRES_USER" -d "$POSTGRES_DB" --clean --if-exists
docker compose up -d n8n n8n-worker

Если restore делается на новом домене, заранее поменяйте WEBHOOK_URL, N8N_HOST, OAuth redirect URL у провайдеров и DNS. Иначе workflows восстановятся, но внешние webhooks и OAuth будут вести в старый адрес.

Restore-drill: проверка, что backup не декоративный

Раз в месяц полезно поднимать тестовый контейнер или отдельный VPS и проходить восстановление. Цель — не “поставить галочку”, а поймать несовпадение версий, отсутствие encryption key, проблемы с volume или забытые binary files.

ПроверкаОжидаемый результат
логин в n8nвладелец и пользователи доступны
открытие credentialscredentials не требуют полного пересоздания
тест HTTP Requestтокен работает или понятно, что его надо обновить
тест Webhookновый домен принимает POST и создаёт execution
binary file из старого executionфайл открывается или известно, что binary data отдельно

Типовые ошибки восстановления

  • Credentials не работают после restore. Почти всегда потерян или изменён N8N_ENCRYPTION_KEY.
  • n8n стартует, но workflows не активируются. Проверьте очередь, Redis, owner, permissions и ошибки migrations в логах.
  • Webhook приходит на старый домен. Обновите WEBHOOK_URL и настройки отправителя: Telegram, Tilda, ЮKassa, amoCRM, Bitrix24.
  • База восстановилась, но файлов нет. Binary data хранилась в volume или external storage, который не попал в backup.
  • Restore занимает слишком долго. Уменьшите retention executions, настройте pruning и вынесите большие файлы во внешнее хранилище.

Связанные материалы