Смена сервера без простоя

Смена сервера для самостоятельно размещённого n8n проходит без заметного простоя, если действовать по принципу blue-green: новый сервер полностью разворачивается параллельно со старым и тестируется с перенесёнными данными, прежде чем переключение DNS перенаправит трафик. При этом важно, чтобы workflow, учётные данные (credentials) и база данных n8n были полностью перенесены на новый сервер с тем же ключом шифрования, поскольку n8n использует N8N_ENCRYPTION_KEY для расшифровки сохранённых учётных данных. Тот, кто забудет этот ключ при переносе, теряет доступ ко всем сохранённым учётным данным, даже если сами workflow удалось импортировать. Актуально на: июль 2026.

Подготовка нового сервера

Прежде чем что-либо переносить, новый сервер (например, свежий инстанс Hetzner Cloud) должен быть настроен и работоспособен, включая Docker или Docker Compose, обратный прокси и правила firewall для портов 80 и 443. Для настроек Hetzner документация n8n по хостингу на Hetzner описывает настройку с Docker Compose и Caddy в качестве обратного прокси, включая постоянные тома (volumes) для данных n8n.

• Docker-окружение: n8n и обратный прокси работают как контейнеры с собственными томами, чтобы данные сохранялись после перезапуска.
• Поддомен для тестирования: Сначала создайте вторую DNS-запись (например, n8n-new.вашдомен.ru), чтобы можно было протестировать новый сервер до переключения основного домена.
• Та же версия n8n: Убедитесь, что версия n8n на новом сервере соответствует версии на старом сервере или сознательно обновлена, чтобы избежать ошибок импорта.

Перенос workflow, учётных данных и базы данных

n8n предоставляет отдельные команды для экспорта и импорта через CLI-команды для экспорта и импорта, которые обрабатывают workflow и учётные данные раздельно. Полную резервную копию можно создать с помощью флагов --backup и --output, а восстановить при импорте с помощью --input и --separate.

• Экспорт workflow: n8n export:workflow --backup --output=backups/latest/ сохраняет все workflow в отформатированном виде и в виде отдельных файлов.
• Экспорт учётных данных: n8n export:credentials --backup --output=backups/latest/ сохраняет учётные данные по-прежнему в зашифрованном виде; опция --decrypted показывает их в открытом виде и должна использоваться только для контролируемых миграций.
• Импорт на новом сервере: n8n import:workflow --separate --input=backups/latest/ и n8n import:credentials --separate --input=backups/latest/ восстанавливают файлы.
• Перенос ключа шифрования: Установите N8N_ENCRYPTION_KEY на новом сервере точно в то же значение, что и на старом сервере, иначе импортированные учётные данные нельзя будет расшифровать.
• Учитывайте папку базы данных: Папка, указанная в N8N_USER_FOLDER, содержит помимо базы данных SQLite и другие локальные конфигурационные данные и также должна входить в резервную копию, если только вы в любом случае не переходите на внешнюю базу данных PostgreSQL.

Согласно документации n8n, эти команды также экспортируют внутренние ID workflow и учётных данных. Если на целевом сервере уже существуют записи с такими же ID, при импорте они будут перезаписаны, это важный момент, если новый сервер настроен не полностью с нуля. Кроме того, импортированные workflow по умолчанию отключены и после проверки их нужно сознательно снова активировать.

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

Переключение DNS: blue-green без простоя

Только когда новый сервер надёжно работает под тестовым поддоменом, переключается собственно домен. Заранее снизьте TTL соответствующей DNS-записи до низкого значения (например, 300 секунд), чтобы переключение вступило в силу быстро. Затем измените A-запись основного домена на IP-адрес нового сервера. В переходный период старый и новый экземпляры работают параллельно, поэтому входящие запросы в зависимости от состояния DNS-кэша могут кратковременно распределяться между обоими серверами. Для workflow, управляемых webhook, это может привести к тому, что отдельные вызовы во время окна переключения попадут на старый, а не на новый сервер, поэтому в этой фазе следует особенно внимательно наблюдать за workflow с интенсивным использованием webhook.

Отключение старого сервера

После переключения DNS подождите как минимум время старого TTL плюс запас на безопасность, прежде чем отключать старый сервер. В это время проверяйте логи нового сервера на входящий трафик и убедитесь, что на старой системе больше не выполняются важные executions. Только когда новый сервер стабильно обрабатывает весь трафик в течение длительного периода, следует остановить старый сервер и заархивировать последнюю резервную копию, прежде чем он будет окончательно удалён. NordFlux применяет этот подход по умолчанию при смене сервера для клиентов с самостоятельно размещённым n8n, чтобы постоянно сохранять немецкий суверенитет данных и контроль над инфраструктурой.

Часто задаваемые вопросы о смене сервера без простоя

Сколько длится смена сервера по схеме blue-green в n8n?

Это зависит от количества workflow, объёма данных и TTL DNS-записей. Собственно перенос данных обычно занимает несколько минут, переключение DNS с запасом на безопасность может занять несколько часов в зависимости от настройки TTL.

Что произойдёт, если ключ шифрования не будет перенесён?

Без идентичного N8N_ENCRYPTION_KEY импортированные учётные данные нельзя расшифровать. Workflow при этом отображаются, но соединения с внешними сервисами не работают, пока учётные данные не будут введены заново.

Достаточно ли простого экспорта базы данных для миграции?

Для полной миграции следует экспортировать как workflow, так и учётные данные с помощью отдельных CLI-команд n8n, в дополнение к собственно папке базы данных или внешнему экземпляру PostgreSQL, если он используется.

Нужно ли отключать n8n во время миграции?

Нет. При подходе blue-green старый сервер остаётся активным и пригодным для использования до успешного переключения DNS. Собственно простой в идеальном случае ограничивается коротким моментом переключения DNS.