--- title: "Postgres restore для n8n: runbook восстановления — Nodbot" source_url: "https://nodbot.ru/playbooks/runbook-postgres-restore/" canonical_url: "https://nodbot.ru/playbooks/runbook-postgres-restore/" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 922 --- # Postgres restore для n8n: runbook восстановления базы ## AI summary Runbook для восстановления Postgres в self-hosted n8n: backup, restore, N8N_ENCRYPTION_KEY, Docker Compose, smoke test, проверки workflows и credentials. ## Best used for Страница объясняет «Postgres restore для n8n: runbook восстановления — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Когда применять этот runbook - 1. Что должно быть в backup - 2. Перед restore: остановить запись - 3. Восстановить в отдельную базу - 4. Проверить encryption key - 5. Smoke test на восстановленной базе - 6. Переключение production ## Source outline # 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 критичны три группы данных: - Данные | Почему важны - Postgres database | workflows, credentials records, users, executions, settings - N8N_ENCRYPTION_KEY | расшифровка credentials и sensitive data - Файлы/volumes n8n | config, binary data, custom files, если используются Если есть только JSON export workflows, это не полный recovery. Он может помочь восстановить логику workflow, но не заменит credentials, users, settings и execution history. ## 2. Перед restore: остановить запись Если старый production ещё жив, переведите систему в режим без записи: - Отключить external webhooks или закрыть traffic на proxy. - Остановить cron/schedule workflows, если возможно. - Остановить workers, чтобы они не продолжали писать executions. - Зафиксировать время freeze. - Сохранить текущие логи и 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 Когда восстановленная база проверена: - Сделать финальный backup текущего состояния, если оно ещё существует. - Остановить n8n main/workers/webhook processors. - Переключить DB target или заменить production DB восстановленной. - Запустить main instance. - Запустить workers после проверки UI и credentials. - Вернуть webhooks/cron traffic. - Проверить ключевые бизнес-сценарии. После восстановления могут быть события, которые пришли во время простоя. Их нужно сверить с внешними системами: платежи, 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 запись нужно остановить. ## Как применять playbook в команде Playbook «Postgres restore для n8n» должен быть понятен человеку, который не писал workflow. Поэтому в нём нужны входной сигнал, частота запуска, критерий тревоги, ответственный и ожидаемое действие после срабатывания. Используйте этот материал как операционную инструкцию: что проверить, где посмотреть логи, как понять масштаб проблемы и когда эскалировать. - Слой | Что зафиксировать | Зачем - Вход | запись из базы или SQL-операция с уникальным ключом, timestamp и результатом транзакции | позволяет повторить проблему без доступа к production-секретам - Контроль | query_duration, conflict_count, transaction_failures, row_count_delta, lock_wait | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | сделать неидемпотентную запись, поймать lock/timeout или незаметно нарушить схему данных | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Postgres restore для n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "operation": "upsert", "dedupe_key": "source_system:external_id", "expected_rows": 1, "on_conflict": "update_changed_fields_only", "audit": {"workflow_id": "...", "execution_id": "..."} } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.