Postgres restore для n8n: runbook восстановления базы ¶

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

Intent: runbook Postgres restore: восстановление базы n8n, encryption key, Docker Compose, smoke test, RTO/RPO и rollback
H1: Postgres restore для n8n: как восстановить базу и не потерять credentials
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 656
New word count: 698

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

Восстановление Postgres для n8n — это не только pg_restore. Нужно сохранить совместимость версии n8n, базы и N8N_ENCRYPTION_KEY: без правильного encryption key credentials и OAuth tokens могут стать нечитаемыми. Безопасный порядок — остановить запись в n8n, восстановить backup в отдельную базу или временный контейнер, проверить workflows/credentials/executions, затем переключать production. Не путайте export workflows JSON с полноценным backup базы.

Когда применять этот runbook ¶

Runbook нужен, если:

• production Postgres повреждён или удалён;
• нужно откатиться после неудачного релиза;
• сервер потерян, но есть backup;
• проверяется restore drill;
• база переезжает на новый хост;
• нужно восстановить n8n после disk full или storage incident.

Цель — вернуть работоспособность без потери workflows, credentials, users, settings, execution history и связей с очередью.

1. Что должно быть в backup ¶

Для self-hosted n8n с Postgres критичны три группы данных:

Если есть только JSON export workflows, это не полный recovery. Он может помочь восстановить логику workflow, но не заменит credentials, users, settings и execution history.

2. Перед restore: остановить запись ¶

Если старый production ещё жив, переведите систему в режим без записи:

1. Отключить external webhooks или закрыть traffic на proxy.
2. Остановить cron/schedule workflows, если возможно.
3. Остановить workers, чтобы они не продолжали писать executions.
4. Зафиксировать время freeze.
5. Сохранить текущие логи и failed/running executions.

Для queue mode важно учитывать main instance, workers и webhook processors. Если часть процессов продолжит писать в базу во время restore, вы получите несогласованное состояние.

3. Восстановить в отдельную базу ¶

Лучший подход — сначала восстановить backup не поверх production, а в отдельную базу/контейнер. Это даёт шанс проверить целостность.

Примерная схема для Docker Compose:

# пример, адаптируйте имена контейнеров и файлов
cat backup.sql | docker compose exec -T postgres psql -U n8n -d n8n_restore

# или для custom dump
docker compose exec -T postgres pg_restore -U n8n -d n8n_restore --clean --if-exists < backup.dump

Не копируйте команды вслепую. Формат backup (plain SQL, custom dump, managed backup) определяет команду восстановления.

4. Проверить encryption key ¶

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

N8N_ENCRYPTION_KEY=...
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_DATABASE=n8n_restore

Если key потерян, база может открыться, но credentials станут непригодны. Это критичный пункт для disaster recovery: encryption key должен храниться отдельно от базы, но достаточно безопасно, чтобы его можно было восстановить.

5. Smoke test на восстановленной базе ¶

До переключения production проверьте:

• UI открывается;
• пользователи/owner доступны;
• workflows отображаются;
• credentials читаются и проходят test connection;
• OAuth credentials не требуют неожиданной reauth;
• Webhook node показывает правильный production URL после env;
• несколько безопасных workflows запускаются;
• execution history открывается;
• binary data доступна, если использовалась.

Не запускайте сразу все active workflows. Сначала проверьте на безопасном subset и staging-домене.

6. Переключение production ¶

Когда восстановленная база проверена:

1. Сделать финальный backup текущего состояния, если оно ещё существует.
2. Остановить n8n main/workers/webhook processors.
3. Переключить DB target или заменить production DB восстановленной.
4. Запустить main instance.
5. Запустить workers после проверки UI и credentials.
6. Вернуть webhooks/cron traffic.
7. Проверить ключевые бизнес-сценарии.

После восстановления могут быть события, которые пришли во время простоя. Их нужно сверить с внешними системами: платежи, CRM, заказы, очереди сообщений, почта.

7. Что записать в restore report ¶

• backup timestamp;
• restore start/end;
• RTO/RPO фактические;
• какая база восстановлена;
• какой n8n version использовался;
• был ли тот же N8N_ENCRYPTION_KEY;
• какие workflows проверены;
• какие события требовали replay;
• какие gaps обнаружены в backup-процессе.

Restore без отчёта не улучшает надёжность. Через месяц команда должна понимать, что именно было проверено.

FAQ ¶

Достаточно ли экспортировать workflows JSON?
Нет. Это не полный backup n8n. Для disaster recovery нужен backup базы, encryption key и связанные файлы/binary data.

Что будет, если потерян N8N_ENCRYPTION_KEY?
Credentials и другие sensitive data могут стать нечитаемыми. Поэтому key должен храниться отдельно и безопасно.

Можно ли восстановить backup поверх production?
Можно, но рискованно. Лучше сначала restore в отдельную базу и smoke test.

Нужно ли останавливать workers?
Да, при queue mode workers могут продолжать выполнять executions и писать в базу. На время restore запись нужно остановить.

{
  "operation": "upsert",
  "dedupe_key": "source_system:external_id",
  "expected_rows": 1,
  "on_conflict": "update_changed_fields_only",
  "audit": {"workflow_id": "...", "execution_id": "..."}
}