Postgres backup и restore для n8n: проверка восстановления ¶

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

Backup Postgres для n8n полезен только тогда, когда команда регулярно проверяет restore. Файл дампа сам по себе не доказывает, что workflows, credentials, executions и binary data можно вернуть после аварии.

Что именно нужно сохранять ¶

В self-hosted n8n база Postgres хранит workflow-конфигурации, credentials в зашифрованном виде, настройки пользователей, executions и системные таблицы. Но для полного восстановления одной базы недостаточно: нужен тот же N8N_ENCRYPTION_KEY, актуальный compose/env, версия образа n8n и, если включены binary data на диске, соответствующий volume или внешнее хранилище.

Backup-стратегия для production ¶

Для небольшого инстанса обычно достаточно ежедневного логического дампа через pg_dump, хранения копий вне сервера и недельного retention. Для нагруженного production лучше использовать snapshot уровня managed database или WAL-архивирование, но это не отменяет test restore. Ключевой вопрос не “есть ли backup”, а “какую потерю данных бизнес готов принять”.

Зафиксируйте RPO и RTO. RPO показывает, сколько данных можно потерять: например, не больше 24 часов executions. RTO показывает, за сколько времени сервис должен вернуться: например, один час на восстановление staging-копии и переключение production. Без этих чисел backup превращается в технический ритуал без бизнес-смысла.

Пример процедуры backup ¶

backup_name: n8n-postgres-daily
schedule: 03:15 Europe/Amsterdam
method: pg_dump custom format + encrypted upload
retention: 14 daily, 8 weekly
includes: database dump, compose file, env checksum, n8n image tag, restore notes
excludes: plaintext credentials, raw secrets in logs
verification: restore to staging every Monday

В production-документе команда должна видеть не только команду pg_dump, но и место хранения копий, ответственного владельца, срок хранения и способ проверки. Если backup лежит на том же диске, который может заполниться или умереть вместе с сервером, это не защита.

Test restore пошагово ¶

1. Создайте изолированную среду. Staging должен иметь отдельный домен, отдельный WEBHOOK_URL и отключённые внешние side effects, чтобы тест не отправил письма клиентам.
2. Разверните Postgres из последнего backup. Проверьте размер базы, список таблиц и отсутствие ошибок импорта.
3. Подставьте тот же encryption key. Без него тест восстановления credentials бессмысленен.
4. Запустите n8n на совместимой версии. Лучше использовать тот же image tag, который был в момент создания backup.
5. Проверьте критичные workflows. Откройте credentials, выполните dry-run, проверьте webhook URL и убедитесь, что внешние действия заблокированы или переведены в тестовый режим.

Частые поломки restore ¶

• дамп успешно создан, но никогда не импортировался в чистую базу;
• encryption key хранится только на сервере, который потерян вместе с базой;
• staging использует production WEBHOOK_URL и случайно принимает реальные события;
• восстанавливается база, но не binary data volume, из-за чего старые файлы executions недоступны;
• retention слишком короткий и чистый backup уже перезаписан после логической ошибки в workflow.

Monitoring и алерты backup ¶

Отслеживайте не только факт запуска cron, но и размер дампа, время выполнения, успешную загрузку в удалённое хранилище и возраст последней проверенной копии. Подозрительно маленький дамп должен создавать алерт так же, как failed job. Для restore-test полезно вести журнал: дата, backup id, версия n8n, результат открытия credentials, ошибки и решение владельца.

У backup должен быть владелец. Если за процесс отвечает “сервер сам”, при аварии никто не знает, где последняя копия, кто имеет ключ расшифровки и какую команду restore выполнять. В runbook укажите путь к хранилищу, retention policy, способ проверки контрольной суммы и контакты человека, который может принять решение об откате.

Владелец backup-процесса ¶

Во время restore-drill фиксируйте не только факт успешного запуска контейнера, но и время восстановления, объём дампа, версию Postgres, наличие encryption key, доступность credentials и корректность binary data. Эти данные превращают backup из “файла на диске” в управляемый процесс с понятным RPO и RTO.

Проверка восстановления должна быть регулярной, а не разовой после настройки backup. Для небольшого n8n-инстанса достаточно ежемесячного restore-drill в отдельное окружение. Для критичных автоматизаций, где через n8n проходят оплаты, заявки или документы, restore-test лучше делать после каждого крупного обновления схемы, миграции базы или изменения политики хранения executions.

Расписание restore-drill ¶

Критерий готовности ¶

Backup-процесс готов, если у вас есть свежий дамп вне production-сервера, сохранённый N8N_ENCRYPTION_KEY, документированный restore-test, проверенные credentials и понятные RPO/RTO. Если команда не может восстановить staging-копию без автора первоначальной установки, backup нельзя считать рабочим.

Что читать дальше ¶

Перед крупным обновлением откройте upgrade checklist. Если вы только уходите с SQLite, начните с миграции SQLite → Postgres. Для ENV и секретов используйте environment variables n8n и общую страницу про backups.