Автоматическое резервное копирование n8n и PostgreSQL: Как не потерять сценарии

В мире DevOps существует главное золотое правило: непроверенная резервная копия равносильна отсутствию резервной копии. Потеря сервера из-за сбоя хостинга, ошибки диска или неудачного обновления ОС может уничтожить месяцы работы по автоматизации бизнеса.

Что обязательно должно входить в регламентный бэкап n8n

Для полного восстановления работоспособности на новом сервере архив должен включать:

• SQL-дамп базы данных PostgreSQL - хранит все сценарии (Workflows), учетные данные (Credentials), историю выполнения и пользователей.
• Файл конфигурации с N8N_ENCRYPTION_KEY - без этого ключа зашифрованные данные из базы невозможно расшифровать.
• Пользовательские скрипты и SSL-сертификаты - настройки обратного прокси и вспомогательные скрипты.

Как выглядят ошибки бэкапа в логах

При сбоях резервного копирования или восстановления в консоли появляются следующие ошибки:

pg_dump: error: connection to database "n8n" failed: FATAL: remaining connection slots are reserved
pg_restore: error: input file appears to be a text format dump. Please use psql.
gzip: stdout: No space left on device

Подводные камни при настройке бэкапов

При самостоятельной настройке резервного копирования чаще всего встречаются следующие ошибки:

• Создание дампа без проверки статуса выполнения: Если контейнер PostgreSQL упал или завис, скрипт с командой pg_dump создаёт пустой файл весом 0 байт, а старые рабочие бэкапы удаляются по сроку давности.
• Избыточная частота бэкапов и переполнение диска: Если запускать создание дампов слишком часто без контроля свободного места, диск сервера быстро переполнится, из-за чего база данных PostgreSQL аварийно остановится. Оптимально настраивать расписание по реальному графику изменений (например, раз в 3 дня) и автоматически удалять устаревшие архивы.
• Попытка восстановить SQL-дамп через pg_restore: Текстовый дамп, созданный обычной командой pg_dump, восстанавливается через клиент psql, а утилита pg_restore требует бинарного custom-формата (-F c).

Скрипт автоматического создания бэкапов через Cron

Ниже приведен надежный Bash-скрипт, который создаёт сжатую архивную копию базы данных PostgreSQL по заданному расписанию и автоматически удаляет архивы старше 30 дней, чтобы не переполнять диск сервера:

#!/bin/bash
BACKUP_DIR="/var/backups/n8n"
DATE=$(date +%Y-%m-%d_%H-%M)
CONTAINER_NAME="postgres-db"
DB_NAME="n8n"
DB_USER="n8n"

mkdir -p "$BACKUP_DIR"

# Создаем дамп и сжимаем в gzip
docker exec -t $CONTAINER_NAME pg_dump -U $DB_USER -d $DB_NAME | gzip > "$BACKUP_DIR/n8n_db_$DATE.sql.gz"

# Удаляем резервные копии старше 30 дней
find "$BACKUP_DIR" -name "n8n_db_*.sql.gz" -mtime +30 -delete
echo "Бэкап успешно завершен: $BACKUP_DIR/n8n_db_$DATE.sql.gz"

Почему важен регламентный тест восстановления

Даже если Cron ежедневно создаёт файлы архивов, битый дамп или изменившаяся версия СУБД могут сделать восстановление невозможным. Именно поэтому профессиональный стандарт DevOps требует регулярного тестового развёртывания архива в изолированном окружении.