Перенос сайта начинается задолго до смены DNS. Нужно подготовить новую среду, проверить её под рабочим именем, согласовать момент прекращения записи данных и продумать возврат. Копирование каталога с файлами решает лишь часть задачи.
Перенос без заметного простоя возможен не для любой архитектуры. Если приложение не умеет работать с общей базой или репликацией, короткое окно обслуживания может оказаться безопаснее одновременной записи на двух независимых серверах.
Составьте карту проекта
Зафиксируйте всё, что нужно сайту: версии PHP и расширений, веб-сервер, базу данных, пользовательские файлы, переменные окружения, сертификаты, очереди, cron, почтовую отправку и внешние интеграции. Для WordPress проверьте также конфигурацию, плагины, тему и права на загрузки.
Уточните, где появляются новые данные. Заказы, заявки, учётные записи и загруженные документы могут храниться в разных местах. От этого зависит финальная синхронизация: недостаточно обновить базу, если после первой копии пользователи добавили новые файлы.
- Проверьте доступ к DNS и регистратору, а не только к панели сервера.
- Запишите действующие A, AAAA, CNAME и почтовые записи.
- Выясните, есть ли привязки интеграций к IP-адресу.
- Определите ответственного за переключение и условия отмены.
Подготовьте резервную копию и новую среду
Сделайте согласованную копию данных и проверьте восстановление. Архив, который ни разу не разворачивали, не заменяет план возврата. Практическая последовательность описана в статье о проверке резервных копий сайта.
Настройте новую среду с нужными версиями компонентов и правами. Не обновляйте одновременно CMS, PHP и сервер, если это не часть согласованного плана: при нескольких крупных изменениях сложнее определить источник ошибки.
На тестовой копии отключите отправку реальных писем, выполнение платежей и повторную обработку webhook. Фоновые задачи новой среды должны оставаться остановленными до назначенного момента: два независимых планировщика могут дважды отправить уведомления или обработать одну операцию.
Проверьте сайт до смены DNS
Направьте только свои тестовые запросы на новый сервер, сохранив рабочее доменное имя. Для этого можно временно изменить локальный hosts или использовать инструмент, который задаёт адрес подключения отдельно от имени сайта. Так проверяются виртуальный хост, HTTPS и поведение приложения без переключения посетителей.
Пройдите главную, разделы, вход, поиск, формы, загрузку файлов и критичные бизнес-сценарии. Для магазина добавьте корзину и тестовый заказ в безопасном режиме. Проверьте сертификат, редиректы, пути к ресурсам и ответы API.
Убедитесь, что тестовая среда не индексируется и не принимает обычный трафик. Ограничение доступа надёжнее, чем один robots.txt: файл управляет поведением добросовестных роботов, но не защищает копию сайта.
Снизьте TTL заранее
TTL определяет срок кеширования DNS-записи. Если уменьшить его одновременно со сменой IP, уже сохранённые ответы могут продолжать действовать по прежнему TTL. Снижение нужно выполнить заранее и дать старому сроку кеширования истечь.
Проверьте записи и для IPv4, и для IPv6. Обновление только A при старой AAAA может отправлять часть посетителей на прежнюю среду. Если меняете ещё и DNS-серверы домена, планируйте это отдельно: кеширование делегирования и кеширование адресов сайта — разные этапы.
Низкий TTL сокращает обычный срок кеширования, но не обещает мгновенное переключение всех клиентов. Поэтому старый сервер нужен и после изменения записей.
Выполните финальную синхронизацию
Выберите один источник записи. При обычном переносе это означает временно остановить изменения на старой стороне, дождаться активных операций и перенести оставшиеся данные. Если доступна репликация, заранее проверьте её состояние и процедуру переключения роли основной базы.
- Зафиксируйте начало окна работ и остановите задачи, способные менять данные.
- Ограничьте новые записи на старой среде или включите согласованный режим обслуживания.
- Синхронизируйте базу, пользовательские файлы и необходимые состояния очередей.
- Проверьте новую среду после синхронизации.
- Обновите DNS и включите обработку задач только на назначенной стороне.
Если часть посетителей ещё попадает на старый сервер, он должен работать по согласованному сценарию. Например, передавать запросы в новую среду или показывать обслуживание для операций записи. Просто оставить обе копии полностью активными опасно: данные могут разойтись.
Продумайте возврат после появления новых данных
До первых записей на новой стороне отмена обычно проще. После новых заказов или заявок возврат требует переноса этих изменений обратно. Одного обратного изменения DNS недостаточно: оно не синхронизирует базы.
Заранее определите, какие ошибки требуют отмены и кто принимает решение. Сохраните конфигурацию DNS и прежней среды, но отдельно опишите порядок работы с данными, созданными после переключения.
Проверьте результат и завершите перенос
Следите за HTTP-ошибками, временем ответа, формами, почтой и интеграциями на обеих сторонах. Не выключайте старую среду, пока не проверены остаточный трафик, фоновые задания и сохранность новых данных.
После стабильной работы верните подходящий TTL, отключите дублирующие задания, обновите мониторинг и резервное копирование. Зафиксируйте новые адреса, доступы и порядок восстановления. Если после переезда сайт стал медленнее, начните с диагностики конкретного сценария.
Чтобы подготовить план переноса вашего проекта, обсудите задачу с HOMEWEB. В обращении укажите CMS, место хранения данных и допустимость окна обслуживания.
Разбираете похожую ситуацию? Расскажите о ней в форме ниже — обсудим, с чего начать именно в вашем случае.
