Backup n8n перед обновлением: что сохранить и как проверить restore ¶
Обновлено: 2026-05-30
Backup n8n перед обновлением должен покрывать не только базу данных, но и encryption key, binary data, compose/ENV-конфигурацию, список активных workflow и проверку восстановления.
Что сохранять ¶
Главная ошибка self-hosted установки — считать backup одним SQL-дампом. В n8n база хранит workflows, executions и credentials в зашифрованном виде, но без правильного N8N_ENCRYPTION_KEY эти credentials нельзя восстановить. Кроме базы нужны volumes, где лежат binary data, пользовательские файлы, локальные exports, а также конфигурация окружения: docker-compose, .env, reverse proxy, cron/systemd и правила backup.
| Компонент | Зачем нужен | Что проверить |
|---|---|---|
| Postgres или SQLite | workflow, credentials, executions, настройки | дамп создаётся без ошибок и читается на restore-сервере |
| N8N_ENCRYPTION_KEY | расшифровка credentials после восстановления | ключ сохранён отдельно от публичного репозитория |
| Binary data volume | файлы, вложения, временные артефакты | понятно, где volume находится и сколько он занимает |
| docker-compose и .env | точное восстановление runtime | версии образов, network, ports, queue mode и DB_* переменные совпадают |
| Workflow export | быстрый ручной контроль критичных сценариев | экспорт содержит последние активные версии |
Backup перед upgrade ¶
Перед обновлением n8n сделайте отдельную точку восстановления, даже если у вас уже есть ежедневный backup. Ежедневный архив может быть создан после того, как ошибка уже попала в базу, а upgrade часто меняет схему, поведение нод или формат executions. Перед началом зафиксируйте текущий image tag, версию n8n, digest контейнера, список критичных workflow и время последнего успешного restore-test.
- Остановите или поставьте на паузу критичные workflow, если обновление может прервать write-действия.
- Сделайте database dump или snapshot с понятным именем версии.
- Сохраните .env, compose-файл, reverse proxy config и encryption key.
- Экспортируйте критичные workflow в JSON для ручной проверки.
- Запишите rollback rule: когда возвращаем старый image, а когда восстанавливаем базу.
Проверка восстановления ¶
Backup считается рабочим только после restore-test. Лучший вариант — отдельный staging-сервер или временный Docker project с другим доменом и отключёнными внешними write-действиями. Восстановите базу, подключите тот же encryption key, проверьте, что credentials открываются, UI загружается, один тестовый workflow запускается, а webhook URL не смотрит на production.
restore_check:
database: restored
encryption_key: matches
credentials: decryptable
critical_workflow: manual smoke-test passed
external_writes: disabled or dry_run
owner_approval: required before production rollback
Не пропускайте проверку credentials. Можно успешно восстановить таблицы базы и при этом получить бесполезный instance, где все подключения к сервисам не расшифровываются.
Операционный runbook для self-hosted backup ¶
Runbook должен быть написан так, чтобы его мог выполнить другой человек. Укажите команды создания дампа, путь к backup, где хранится ключ, как проверить размер архива, как распаковать volume, как поднять staging и какие workflow нельзя запускать автоматически. Отдельно опишите контакты владельцев: backup может быть технически успешным, но бизнес должен подтвердить допустимую потерю данных.
Как не потерять секреты и доступы ¶
- Не храните encryption key только внутри одного сервера, который может быть потерян.
- Не кладите .env с секретами в публичный репозиторий вместе с документацией.
- Не отправляйте backup базы в канал поддержки без шифрования.
- Не проверяйте restore на production-домене, если webhooks могут принять реальные события.
- Не удаляйте старый snapshot до завершения smoke-test после upgrade.
Smoke-test после изменения ¶
После обновления проверьте UI login, список workflow, расшифровку credentials, один manual execution, один webhook снаружи, запись в тестовый внешний сервис и отсутствие массовых ошибок в логах. Если используется queue mode, отдельно проверьте main process, workers и Redis. Smoke-test должен быть коротким, но он обязан покрывать путь от входящего события до безопасного результата.
Критерий готовности ¶
Backup-процесс готов, когда известен RPO/RTO, архив создаётся регулярно, restore проверен на изолированном окружении, encryption key доступен ответственным людям, а rollback описан до начала upgrade. Если есть только “где-то лежит дамп”, это не backup, а неподтверждённая копия.
Страница backup не должна превращаться в общий гайд по Docker, Postgres tuning или disaster recovery. Здесь важен конкретный вопрос: какие данные n8n надо сохранить до изменения и как доказать, что их можно восстановить. Для настройки базы, миграции SQLite или долгосрочного DR-плана нужны отдельные материалы и внутренние ссылки.
Как не смешивать сценарии ¶
В production backup — это часть release-процесса. Перед upgrade ответственный фиксирует версию, делает копию, запускает restore-test или проверяет свежий restore-test, выполняет обновление, прогоняет smoke-test и только потом удаляет временные артефакты. Если smoke-test показывает ошибку credentials, webhook или critical workflow, решение о rollback принимает владелец процесса вместе с администратором, а не случайный исполнитель.
Production-подход ¶
- известно, где лежит последний успешный dump базы;
- отдельно сохранён N8N_ENCRYPTION_KEY;
- проверено восстановление credentials на staging;
- описано, какие workflow нужно остановить перед restore;
- есть журнал восстановления: кто, когда, какую копию применял и почему.
Практический минимум перед публикацией ¶
Минимальная политика хранения: несколько ежедневных копий, несколько недельных копий и отдельные pre-upgrade snapshots с привязкой к версии. В названии архива должны быть дата, версия n8n, тип базы и пометка manual/auto. Если backup уходит в S3, объектное хранилище или NAS, проверьте lifecycle rules, шифрование, права доступа и возможность скачать архив без production-сервера.
Для n8n лучше сочетать регулярный автоматический backup и ручную точку восстановления перед рискованными изменениями. Автоматический backup закрывает случайные сбои, удаление workflow и проблемы диска. Ручной pre-upgrade backup нужен перед изменением версии n8n, схемы Postgres, reverse proxy, queue mode или storage для binary data. У этих копий разный смысл, поэтому их не стоит хранить в одной папке без понятных имён.
Расписание и хранение backup ¶
Что читать дальше ¶
Для связанной настройки откройте ENV-переменные n8n, Postgres backup и restore, upgrade checklist и маршрут self-hosted администратора.