---
title: "Backup n8n перед обновлением: чеклист — Nodbot"
source_url: "https://nodbot.ru/hosting/backups/"
canonical_url: "https://nodbot.ru/hosting/backups/"
language: "ru"
content_type: "HostingGuide"
section: "hosting"
generated_at: "2026-05-30"
word_count_source: 864
---

# Backup n8n перед обновлением: чеклист

## AI summary

Практический чеклист backup n8n перед обновлением: какие данные сохранять, почему важен encryption key, как проверять restore и когда применять rollback.

## Best used for

Материал помогает выбрать правильный маршрут по теме «Backup n8n перед обновлением: чеклист», проверить практические шаги и избежать смешивания соседних интентов внутри базы знаний Nodbot.

## Key topics

- Что сохранять
- Backup перед upgrade
- Проверка восстановления
- Операционный runbook для self-hosted backup
- Как не потерять секреты и доступы
- Smoke-test после изменения
- Критерий готовности
- Как не смешивать сценарии
- Production-подход
- Практический минимум перед публикацией
- Расписание и хранение backup
- Что читать дальше

## Source outline

# Backup n8n перед обновлением: что сохранить и как проверить restore [¶](#backup-n8n-chto-sohranyat-pered-obnovleniem "Permanent link")

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

Сохранить в мой план[Открыть мой план](/my-plan/)

**Backup n8n перед обновлением должен покрывать не только базу данных, но и encryption key, binary data, compose/ENV-конфигурацию, список активных workflow и проверку восстановления.**

## Что сохранять [¶](#chto-sohranyat "Permanent link")

Главная ошибка 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 [¶](#backup-pered-upgrade "Permanent link")

Перед обновлением n8n сделайте отдельную точку восстановления, даже если у вас уже есть ежедневный backup. Ежедневный архив может быть создан после того, как ошибка уже попала в базу, а upgrade часто меняет схему, поведение нод или формат executions. Перед началом зафиксируйте текущий image tag, версию n8n, digest контейнера, список критичных workflow и время последнего успешного restore-test.

1. Остановите или поставьте на паузу критичные workflow, если обновление может прервать write-действия.
2. Сделайте database dump или snapshot с понятным именем версии.
3. Сохраните .env, compose-файл, reverse proxy config и encryption key.
4. Экспортируйте критичные workflow в JSON для ручной проверки.
5. Запишите rollback rule: когда возвращаем старый image, а когда восстанавливаем базу.

## Проверка восстановления [¶](#proverka-vosstanovleniya "Permanent link")

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 [¶](#operacionnyy-runbook-dlya-self-hosted-backups "Permanent link")

Runbook должен быть написан так, чтобы его мог выполнить другой человек. Укажите команды создания дампа, путь к backup, где хранится ключ, как проверить размер архива, как распаковать volume, как поднять staging и какие workflow нельзя запускать автоматически. Отдельно опишите контакты владельцев: backup может быть технически успешным, но бизнес должен подтвердить допустимую потерю данных.

## Как не потерять секреты и доступы [¶](#kak-ne-poteryat-sekrety-i-dostupy "Permanent link")

* Не храните encryption key только внутри одного сервера, который может быть потерян.
* Не кладите .env с секретами в публичный репозиторий вместе с документацией.
* Не отправляйте backup базы в канал поддержки без шифрования.
* Не проверяйте restore на production-домене, если webhooks могут принять реальные события.
* Не удаляйте старый snapshot до завершения smoke-test после upgrade.

## Smoke-test после изменения [¶](#smoke-test-posle-izmeneniya "Permanent link")

После обновления проверьте UI login, список workflow, расшифровку credentials, один manual execution, один webhook снаружи, запись в тестовый внешний сервис и отсутствие массовых ошибок в логах. Если используется queue mode, отдельно проверьте main process, workers и Redis. Smoke-test должен быть коротким, но он обязан покрывать путь от входящего события до безопасного результата.

## Критерий готовности [¶](#kriteriy-gotovnosti-hosting-backups "Permanent link")

Backup-процесс готов, когда известен RPO/RTO, архив создаётся регулярно, restore проверен на изолированном окружении, encryption key доступен ответственным людям, а rollback описан до начала upgrade. Если есть только “где-то лежит дамп”, это не backup, а неподтверждённая копия.

Страница backup не должна превращаться в общий гайд по Docker, Postgres tuning или disaster recovery. Здесь важен конкретный вопрос: какие данные n8n надо сохранить до изменения и как доказать, что их можно восстановить. Для настройки базы, миграции SQLite или долгосрочного DR-плана нужны отдельные материалы и внутренние ссылки.

## Как не смешивать сценарии [¶](#kak-ne-smeshivat-scenariiy "Permanent link")

В production backup — это часть release-процесса. Перед upgrade ответственный фиксирует версию, делает копию, запускает restore-test или проверяет свежий restore-test, выполняет обновление, прогоняет smoke-test и только потом удаляет временные артефакты. Если smoke-test показывает ошибку credentials, webhook или critical workflow, решение о rollback принимает владелец процесса вместе с администратором, а не случайный исполнитель.

## Production-подход [¶](#production-podhod "Permanent link")

* известно, где лежит последний успешный dump базы;
* отдельно сохранён N8N\_ENCRYPTION\_KEY;
* проверено восстановление credentials на staging;
* описано, какие workflow нужно остановить перед restore;
* есть журнал восстановления: кто, когда, какую копию применял и почему.

## Практический минимум перед публикацией [¶](#prakticheskii-minimum-pered-publikaciei "Permanent link")

Минимальная политика хранения: несколько ежедневных копий, несколько недельных копий и отдельные 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 [¶](#raspisanie-i-hranenie-backup "Permanent link")

## Что читать дальше [¶](#chto-chitat-dalshe "Permanent link")

Для связанной настройки откройте [ENV-переменные n8n](/hosting/env-vars/), [Postgres backup и restore](/hosting/postgres-backup-restore/), [upgrade checklist](/hosting/upgrade-checklist/) и маршрут [self-hosted администратора](/learning/self-hosted-admin-path/).