Backup и update n8n: как обновляться без потери данных ¶

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

Обновление n8n должно быть процедурой, а не импровизацией. В self-hosted установке вы отвечаете за базу, volumes, env, encryption key и совместимость workflow. Хороший backup позволяет обновляться спокойно и откатываться быстро.

Что бэкапить ¶

Минимальный набор: PostgreSQL dump или SQLite-файл, volume с данными n8n, .env, Docker Compose, N8N_ENCRYPTION_KEY, экспорт критичных workflow. Encryption key особенно важен для восстановления credentials.

Порядок update ¶

1. Прочитайте release notes.
2. Сделайте backup.
3. Остановите n8n или выберите maintenance-окно.
4. Обновите image/tag.
5. Запустите контейнеры и проверьте логи.
6. Протестируйте критичные workflow, webhook и OAuth.

Rollback ¶

План отката нужен до обновления. Он включает старый image tag, восстановление базы и проверку credentials. Если версия уже выполнила миграции базы, откат может быть сложнее, поэтому для критичных проектов полезен staging.

Проверка после update ¶

UI открывается по HTTPS, production webhook вызывается, OAuth credentials работают, расписания запускаются в нужной timezone, failed executions не растут неожиданно.

Production-подход: изменение, проверка, откат ¶

Backup и update n8n: как обновляться без потери данных относится к инфраструктуре, поэтому главная ошибка — менять конфигурацию без плана отката. Перед правкой сохраните текущий compose/env, сделайте backup базы, проверьте значение N8N_ENCRYPTION_KEY и подготовьте smoke-test для UI, webhook, schedule trigger, credentials и worker.

Что нельзя смешивать в одной статье ¶

Минимальные артефакты эксплуатации ¶

• таблица env-переменных с владельцем и датой последней проверки
• инструкция восстановления из backup на чистом окружении
• список критичных workflows и их внешних зависимостей
• алерт на failed executions, рост очереди, место на диске и ошибки Postgres/Redis
• журнал обновлений n8n: версия, дата, что проверяли, как откатываться

Runbook-блок: как выполнять безопасно

Материал Backup и update n8n: как обновляться без потери данных относится к эксплуатации n8n, поэтому его нельзя выполнять «на глаз». Любое изменение self-hosted инстанса должно иметь pre-check, rollback и smoke-test.

Pre-flight checklist

• сделайте backup базы, workflows и переменных окружения;
• зафиксируйте текущую версию n8n, Node.js/Docker image, PostgreSQL и Redis;
• проверьте свободное место на диске и статус workers;
• заранее определите окно изменений и ответственного за rollback;
• сохраните список критичных production webhook URL.

Smoke-test после изменения

1. Откройте UI и проверьте login, credentials и список workflows.
2. Запустите ручной workflow без внешних побочных эффектов.
3. Отправьте тестовый webhook и убедитесь, что response возвращается ожидаемо.
4. Проверьте queue/worker logs, если используется queue mode.
5. Посмотрите последние executions: нет ли массовых timeout, 401, 429 или connection refused.

Rollback-критерии

Откатывайте изменение, если UI недоступен, production webhooks возвращают 5xx, workers не забирают задачи, credentials не расшифровываются или новая версия ломает критичный workflow. Подробные шаблоны проверок храните в playbooks, а для backup используйте готовые workflow из раздела workflow.

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY

Что читать дальше ¶

Для базы см. PostgreSQL, для переменных — environment variables.

Чеклист production ¶

Перед использованием self-hosted n8n в боевых процессах проверьте не только запуск контейнера, но и восстановление. Установка считается готовой, когда вы знаете, где лежит база, как восстановить credentials, какие env отвечают за публичный домен и кто получает уведомление при сбое.

• Домен работает по HTTPS, а production webhook открывается извне.
• PostgreSQL и volumes бэкапятся по расписанию.
• N8N_ENCRYPTION_KEY сохранён вне сервера.
• Доступ к editor ограничен пользователями, сетью или proxy.
• После обновления проверяются webhook, OAuth и критичные workflow.

Типичный риск ¶

Главная ошибка self-hosted установки — считать, что если UI открылся, инфраструктура готова. Для n8n важны публичные callback URL, сохранность базы, секреты, timezone расписаний и процедура rollback. Эти вещи лучше проверить до первого критичного workflow.