Переезд сервера без потери данных: чек-лист и грабли

Разбор собственного переезда: датацентр, где стоял мой сервер, попал под отключение, и счёт шёл на часы. Всё ниже — не теория, а то, что реально случилось, с цифрами.

Что переезжало

На одном сервере жили сайт и весь боевой контур автоматизаций: n8n с воркером, база, очередь, прокси и раздача статики — шесть контейнеров, 53 сценария (51 активный), 12 подключений к сервисам. На этот же n8n завязаны AI-коуч и другие продукты. Упасть на сутки — значит остановить всё сразу.

Шаг 1. Сначала бэкап, потом всё остальное

Пока старый сервер жив — забрать с него всё, что понадобится для восстановления, и проверить, что забранное целое:

• дамп базы в двух форматах — для быстрого восстановления и для чтения глазами;
• каждый сценарий отдельным файлом через API — если база не поднимется, их можно залить заново;
• конфиги: переменные окружения, docker-compose, конфиг веб-сервера;
• копия статики сайта.

Сверка — побайтово с оригиналами на сервере. «Скачалось без ошибок» — не доказательство.

Шаг 2. Хостинг — под задачу, а не «какой подешевле»

Главный вопрос был не цена, а доступность внешних API. Крупные AI-провайдеры режут запросы с российских IP, поэтому для контура, который постоянно ходит в языковые модели, нужен зарубежный сервер. Российский вариант для этой задачи отпадал сразу, как бы удобно он ни стоил.

Шаг 3. Поднять и сверить до переключения

Новый сервер собирается и проверяется, пока трафик ещё идёт на старый. Критерий готовности — не «контейнеры запустились», а совпадение один в один: 53 сценария, 12 подключений, 51 активный — как в оригинале.

Шаг 4. Переключить DNS и выключить старый сервер последним

DNS переключается только после сверки. А старый сервер выключается последним, не первым — сначала убедиться, что новый реально работает под живой нагрузкой. Но у этого правила есть обратная сторона (грабля №4 ниже).

Шесть граблей, которые всплыли по дороге

1. Порт занят тем, чего вы не ставили

Новый VPS при заказе сам поставил панель управления, а с ней — системный веб-сервер на порту 80. Прокси не смог его занять. Перед запуском проверить, что порты свободны.

2. Контейнер «работает», но ничего не слушает

После исправления конфликта портов повторный запуск просто стартовал уже созданный (сломанный) контейнер, не пересоздав его. Статус «running», а порты 80/443 пустые. Лечится принудительным пересозданием контейнера.

3. База восстановилась, а приложение её не видит

Восстановленные таблицы получили другого владельца, чем пользователь, под которым работает n8n. Он падал с ошибкой «таблица уже существует». Нужна явная выдача прав на все таблицы и на будущие объекты.

4. Два живых сервера — двойные запуски по расписанию

Пока старый сервер не выключен, на нём тоже работают все сценарии. Вебхуки после смены DNS уходят на новый, а задачи по расписанию тикают на обоих независимо. Отложенная публикация сработала дважды — одновременно на двух серверах. Сценарии по расписанию на старом сервере нужно выключить сразу после переключения.

5. Внешняя база пускает только старый IP

Облачная база с данными продуктов пускала подключения только из белого списка IP — там был старый адрес. На новом сервере сценарии получали «соединение отклонено». Все внешние белые списки (базы, API, партнёрские кабинеты) нужно выписать заранее и добавить новый адрес до переключения.

6. Забыли то, что жило вне контейнеров

Самая тихая грабля. Ежедневный бэкап продуктовой базы и учёт расходов на AI жили в системном cron старого сервера — не в n8n. Чек-лист переезда их не покрывал, и они молча перестали работать. Ничего не упало, никто не узнал — пока через две недели не всплыло на аудите. Инвентаризация перед переездом должна включать cron, скрипты в домашних папках и ключи.

Ещё два момента после переключения

• Сертификат. Сразу после смены DNS Let's Encrypt какое-то время стучится на старый IP и упирается в лимит неудачных проверок. Лимит временный — через пару минут сертификат выпустился сам. Паниковать и перезапускать всё подряд не нужно.
• Проверка с мобильного интернета. Операторы связи в РФ иногда фильтруют IP хостеров, и сайт открывается везде, кроме сотовой сети. Проводные проверки этого не видят. Перед переключением стоит открыть сайт по новому адресу с телефона без Wi-Fi.

Коротко: чек-лист

1. Бэкап всего + побайтовая сверка.
2. Инвентаризация вне контейнеров: cron, скрипты, ключи.
3. Список внешних белых списков IP — добавить новый адрес заранее.
4. Хостинг под доступность нужных API и требования 152-ФЗ.
5. Поднять новый, сверить количество сценариев, подключений, активных.
6. Проверить с мобильного интернета.
7. Переключить DNS, выключить расписания на старом.
8. Выключить старый сервер последним.

Кейс на сайте: Серверная инфраструктура для AI-продуктов.