Сайт переехал, а заказы остались на старом сервере: как сменить хостинг без потери данных

Переезд сайта часто считают простой технической операцией: скопировать файлы, перенести базу данных, изменить DNS — готово. Главная страница открывается с нового сервера, администратор проверяет каталог и закрывает старый аккаунт.

Через день выясняется, что часть заказов исчезла, письма с форм не приходят, платёжная система отправляла уведомления на старый сервер, а планировщик дважды запускал одну и ту же задачу.

Проблема не обязательно в CMS или новом хостинге. В течение переходного периода сайт мог одновременно существовать в двух рабочих версиях: одни посетители попадали на новый сервер, другие — на старый. Каждая версия записывала данные в собственную базу.

Скопировать сайт — ещё не значит перенести его​

У современного сайта есть как минимум три слоя:

• файлы CMS, шаблонов, расширений и загруженных изображений;
• база данных с пользователями, заказами, материалами и настройками;
• внешнее окружение: почта, DNS, SSL-сертификаты, cron, очереди, платёжные уведомления, CRM и сторонние API.

Если перенести только файлы и базу, сайт может открыться, но не работать как единая система.

Для Joomla важно проверить configuration.php, пути к временным файлам и журналам, параметры базы данных и права на каталоги. У WordPress — wp-config.php, постоянные ссылки, фоновые задачи и настройки плагинов. В интернет-магазине дополнительно появляются платёжные уведомления, выгрузки товаров, синхронизация остатков и обмен с CRM.

Именно такие детали чаще всего ломаются не во время копирования, а после переключения трафика.

Почему посетители попадают на разные серверы​

Когда владелец меняет IP-адрес в DNS, новая запись не появляется мгновенно у всех пользователей. DNS-резолверы, провайдеры и локальные устройства могут некоторое время хранить прежний адрес в кэше.

Срок хранения задаётся параметром TTL. Но снизить TTL за минуту до переезда недостаточно: старая запись с прежним сроком уже могла сохраниться в кэше. Поэтому значение уменьшают заранее и только потом начинают переключение.

Пока обновление распространяется, возникает переходный период:

• администратор уже видит новый сервер;
• часть посетителей продолжает открывать старый;
• поисковые роботы и внешние сервисы могут использовать разные адреса;
• формы, заказы и комментарии записываются в две независимые базы.

DNS управляет направлением трафика, но не синхронизирует данные. Если два сервера одновременно принимают изменения, базы начинают расходиться.

Не совмещайте переезд с обновлением сайта​

Распространённая ошибка — одновременно сменить сервер, версию PHP, базу данных, CMS и несколько расширений. Если после запуска появится ошибка, определить её источник будет сложно.

Безопаснее сначала воспроизвести на новом сервере совместимое окружение:

• ту же рабочую версию PHP;
• необходимые PHP-модули;
• совместимую версию MySQL или MariaDB;
• действующие правила веб-сервера;
• прежнюю структуру каталогов и прав доступа.

После стабильного переезда можно отдельно обновлять PHP, CMS и расширения. Одна операция — один контролируемый риск.

Сначала составьте карту сайта​

До копирования нужно понять, что именно предстоит переносить. Минимальный список выглядит так:

• файлы сайта и пользовательские загрузки;
• база данных и отдельный пользователь для подключения;
• версия PHP и установленные модули;
• задачи cron и фоновые очереди;
• почтовые ящики и способ отправки писем с сайта;
• SSL-сертификат;
• записи A, AAAA, CNAME, MX и TXT;
• платёжные уведомления и вебхуки;
• интеграции с CRM, складом, телефонией и аналитикой;
• IP-адреса, добавленные в белые списки внешних сервисов;
• резервная копия и проверенный способ восстановления.

Отдельное внимание стоит уделить записи AAAA. Если изменить только IPv4-адрес в записи A, часть пользователей с IPv6 может продолжить попадать на прежний сервер.

Подготовьте новый сервер до изменения DNS​

Первую копию сайта можно перенести заранее, пока старая версия продолжает работать. После импорта файлов и базы новый сервер проверяют через временный адрес или локальную подмену домена.

Недостаточно увидеть главную страницу. Нужно пройти реальные пользовательские сценарии:

• открыть внутренние страницы;
• войти в административную панель;
• отправить форму;
• создать тестовый заказ;
• проверить письмо клиенту и администратору;
• загрузить изображение или документ;
• запустить задачу cron;
• проверить оплату в тестовом режиме;
• посмотреть журналы ошибок;
• убедиться, что ссылки, редиректы и HTTPS работают правильно.

На этом этапе трафик ещё не переключён, поэтому ошибки можно исправлять спокойно.

Как синхронизировать данные перед запуском​

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

Для небольшого сайта надёжнее предусмотреть короткое окно обслуживания:

1. Включить режим обслуживания или временно запретить операции записи.
2. Остановить cron и фоновые обработчики на старом сервере.
3. Сделать финальный экспорт базы данных.
4. Перенести новые изображения и документы, появившиеся после первой копии.
5. Импортировать актуальную базу на новом сервере.
6. Проверить сайт и изменить DNS.
7. Запустить cron только на новом сервере.

Короткая контролируемая пауза безопаснее, чем формальный «переезд без простоя», после которого приходится вручную собирать заказы из двух баз.

Если сайт нельзя остановить даже на несколько минут, потребуется более сложная схема: репликация базы, синхронизация изменившихся файлов или временное проксирование запросов на один узел. Такой перенос лучше заранее планировать с системным администратором.

Не забудьте про почту и внешние сервисы​

Смена веб-сервера не всегда означает перенос почты. Если почтовые ящики обслуживаются отдельным провайдером, записи MX не нужно менять вместе с адресом сайта.

Но сам сайт может отправлять письма через локальный почтовый сервер. После переезда формы перестанут работать, если не перенести SMTP-настройки, SPF, DKIM и разрешённые IP-адреса.

То же относится к платёжным системам и CRM. Нужно проверить:

• куда приходят уведомления об оплате;
• разрешён ли новый IP во внешних сервисах;
• не остались ли обработчики на старом сервере;
• не запускаются ли задания одновременно на двух узлах;
• доходят ли письма клиенту и администратору.

Успешно открывшаяся главная страница ничего не говорит о работе этих связей.

Когда перенос лучше доверить инженерам​

Самостоятельно перенести небольшой информационный сайт вполне реально. Для магазина, SaaS, CRM или проекта с постоянными изменениями важнее заранее согласовать окно переключения, финальную синхронизацию и порядок отката.

Например, у Hostyrex подготовка к миграции включает проверку программного окружения, DNS TTL, базы данных, резервной копии, момента переключения и сценария возврата на старый сервер. Для размещения доступны KVM VPS на NVMe и выделенные серверы, а миграцию, мониторинг и резервное копирование можно согласовать в рамках отдельного managed-сопровождения.

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

Резервная копия и план отката — не одно и то же​

Архив на диске ещё не гарантирует, что сайт можно восстановить. Резервную копию нужно хотя бы один раз развернуть в тестовом окружении и проверить, что внутри действительно есть актуальные файлы и база.

План отката отвечает на другие вопросы:

• при каких ошибках возвращаем трафик на старый сервер;
• кто принимает это решение;
• сколько времени отведено на исправление;
• что делать с заказами, появившимися после переключения;
• какой сервер считается главным источником данных;
• как избежать повторного запуска cron и платёжных обработчиков.

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

Чек-лист перед отключением старого сервера​

Старый хостинг можно закрывать только после проверки:

• сайт открывается с нового IP по HTTP и HTTPS;
• формы, регистрация и заказы работают;
• письма доходят;
• платёжные уведомления обрабатываются;
• cron запущен только на новом сервере;
• новые файлы сохраняются в правильные каталоги;
• в журналах нет массовых ошибок 404 и 500;
• старый сервер больше не принимает пользовательские изменения;
• резервная копия восстановлена в тесте;
• понятен порядок отката;
• на старый IP больше не приходит значимый трафик.

Удачный переезд — это не момент, когда открылась главная страница. Это ситуация, в которой не потерялся ни один заказ, письмо или платёж, а команда может объяснить, как вернуться назад, если новый сервер поведёт себя не так, как ожидалось.