Backup restore drill n8n: проверка восстановления ¶

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

Короткий ответ ¶

Backup для n8n считается рабочим только после успешного restore drill. Недостаточно хранить дамп базы или архив Docker volume: нужно поднять отдельный тестовый контур, восстановить Postgres, файлы, .env, N8N_ENCRYPTION_KEY, workflows и credentials, затем выполнить smoke tests. Главная цель drill — доказать RTO/RPO цифрами, а не верой в то, что backup «где-то есть».

Почему обычного backup недостаточно ¶

Многие команды уверены, что у них есть backup, пока не пробуют восстановить n8n. В момент аварии выясняется, что дамп не той базы, volume не содержит нужных файлов, encryption key остался только в старом контейнере, credentials не расшифровываются, а инструкция восстановления понятна только человеку, который сейчас в отпуске.

Restore drill нужен, чтобы заранее найти эти проблемы. Это учебная тревога: вы восстанавливаете n8n в отдельной среде, не трогая production, и фиксируете реальное время восстановления, потери данных и ручные шаги.

Что обязательно входит в backup ¶

Если используется queue mode, в drill нужно включить workers и Redis-конфигурацию. Если используется внешнее S3-like storage для binary data, отдельно проверяйте доступ и права.

Перед началом drill ¶

Не делайте первый restore drill на production. Нужен отдельный сервер, отдельная БД, отдельный домен или внутренний URL. Цель — проверить восстановление, а не создать второй живой инстанс, который случайно начнёт отправлять письма, webhooks или CRM-записи.

Подготовьте:

• свежий backup БД;
• копию .env без лишних production-секретов;
• N8N_ENCRYPTION_KEY из production-контура;
• версию Docker image или package version;
• список critical workflows для smoke tests;
• тестовые credentials или безопасный режим для внешних API;
• человека, который не писал исходную инструкцию.

Последний пункт важен. Если восстановить может только автор инфраструктуры, runbook ещё не готов.

Порядок восстановления ¶

Ниже примерный порядок для self-hosted Docker Compose с Postgres. Команды нужно адаптировать под вашу инфраструктуру.

# 1. Поднять пустую тестовую БД
sudo docker compose up -d postgres

# 2. Восстановить дамп Postgres
cat backup_n8n.sql | sudo docker compose exec -T postgres psql -U n8n -d n8n

# 3. Проверить, что env содержит тот же encryption key
 grep N8N_ENCRYPTION_KEY .env

# 4. Поднять n8n в изолированной среде
sudo docker compose up -d n8n

# 5. Посмотреть логи запуска
sudo docker compose logs --tail=200 n8n

Не подключайте восстановленный контур к настоящим webhooks, CRM и платёжным системам до smoke tests. Для проверки достаточно тестовых payload и отключённых write-действий.

Проверка credentials ¶

Самая частая проблема после восстановления — workflows видны, но credentials не работают. Причина обычно в encryption key, версии, env или некорректном переносе БД.

Проверьте три типа credentials:

Если credentials не расшифровываются, не пытайтесь массово пересоздавать их до анализа ключа. Сначала сравните N8N_ENCRYPTION_KEY, source backup и версию инстанса.

Smoke tests после восстановления ¶

Smoke test должен доказать, что восстановленный n8n не просто открыл UI, а выполняет реальные workflow.

Для production-критичных сценариев добавьте бизнес-проверку: заявка появилась в тестовой CRM, письмо не ушло клиенту, платёж не создан, но mapping корректен.

Как измерять RTO и RPO ¶

RTO — сколько времени нужно, чтобы вернуть сервис. RPO — сколько данных можно потерять между последним backup и аварией.

Записывайте факты:

• время начала drill;
• время получения backup;
• время восстановления БД;
• время первого успешного логина;
• время первого успешного workflow;
• сколько executions или payload потерялись относительно production;
• какие шаги потребовали ручной догадки.

Если RTO получился 3 часа, не пишите в документации «примерно 30 минут». Drill нужен именно для честных цифр.

Частые провалы restore drill ¶

Рекомендованный график ¶

• После первого production-запуска — drill в течение первой недели.
• После изменения БД, queue mode, storage или secrets — внеплановый drill.
• Для критичных workflow — раз в квартал.
• Для небольшого внутреннего инстанса — минимум раз в полгода.

Контрольный чеклист ¶

• Backup включает БД, env, encryption key, volumes и инструкцию запуска.
• Restore проводится в отдельной среде, не в production.
• Credentials проверены read-only тестами.
• Critical workflows открываются и выполняются.
• Есть измеренные RTO/RPO.
• Документированы ошибки drill и конкретные задачи.
• Следующая дата проверки назначена.

FAQ ¶

Можно ли восстановить credentials без N8N_ENCRYPTION_KEY?
В нормальном сценарии нет: credentials зашифрованы. Если ключ потерян, workflows могут остаться видимыми, но секреты придётся пересоздавать.

Достаточно ли экспортировать workflows в JSON?
Нет. Экспорт помогает как дополнительная копия, но полноценное восстановление требует БД, credentials, env и часто binary data.

Нужно ли хранить executions в backup?
Для некоторых команд да: executions помогают расследовать ошибки и доказать обработку событий. Но объём может быть большим, поэтому retention и backup нужно согласовать заранее.

Как безопасно тестировать восстановленные webhooks?
Используйте отдельный домен или test URL, отключите реальные провайдеры и отправляйте payload вручную. Не подключайте production webhook provider к восстановленному инстансу.

Кто должен проводить drill?
Лучше дежурный или второй инженер, а не автор runbook. Так вы проверите, что инструкция исполнима без устных пояснений.

{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}