Перенос сайта на другой хостинг без простоя

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

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

Определите, что именно переезжает

Составьте перечень до заказа новой площадки. В него входят не только файлы сайта:

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

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

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

Подготовьте новую площадку отдельно от старой

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

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

На этом этапе новая площадка не должна отправлять реальные письма клиентам или выполнять те же задания, что и старая. Иначе два cron-задания могут дважды выставить счёт или разослать одинаковые уведомления. До переключения держите такие процессы выключенными либо направляйте их в тестовый режим.

Проверьте сайт под его доменным именем

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

Для одного компьютера можно временно сопоставить домен с новым IP в локальном файле hosts. Изменение действует только на этом устройстве и не затрагивает посетителей. После сохранения откройте несколько страниц, войдите в административную часть, отправьте тестовую форму и проверьте ресурсы в инструментах разработчика браузера. По окончании удалите временную строку, иначе компьютер продолжит обходить публичный DNS.

Если HTTPS уже настроен, сертификат на новой площадке должен соответствовать домену. Некоторые центры сертификации подтверждают владение через HTTP-запрос, поэтому выпуск до смены DNS может потребовать DNS-проверку или временное управление проверочным путём на старом сервере.

Подготовьте DNS заранее

TTL задаёт, как долго кеширующий резолвер может хранить ответ. За несколько прежних TTL до переноса уменьшите его до умеренного значения, разрешённого DNS-провайдером. Важно дождаться, пока старое большое значение перестанет действовать: уменьшение TTL за минуту до переключения не обновит уже существующие кеши.

Меняйте только записи, относящиеся к сайту. При переезде веб-хостинга обычно меняются A и, если используется IPv6, AAAA. NS менять не требуется, если авторитетный DNS-провайдер остаётся прежним. Не трогайте MX и почтовые TXT-записи, если почта никуда не переезжает.

Если новый сервер не обслуживает IPv6, удалите или обновите старую AAAA-запись. Иначе часть посетителей будет по-прежнему попадать на прежний адрес, хотя A уже указывает правильно.

Синхронизируйте последние изменения

У статического сайта достаточно повторно загрузить файлы, изменившиеся после первой копии. Для динамического сайта выберите один из трёх вариантов:

1. Короткий режим только для чтения. Остановите новые записи, сделайте финальный экспорт базы и файлов, восстановите их на новой площадке и переключите DNS.
2. Репликация базы. Старая площадка остаётся источником до контролируемого переключения роли. Этот вариант сокращает окно записи, но требует проверки совместимости и навыков сопровождения.
3. Прикладная синхронизация. Подходит, когда система умеет переносить изменения через журнал событий или штатный механизм миграции.

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

Переключите трафик и наблюдайте

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

На новой площадке контролируйте:

• долю ответов 4xx и 5xx;
• ошибки приложения и базы данных;
• загрузку процессора, памяти и диска;
• выполнение очередей и заданий по расписанию;
• срок и цепочку TLS-сертификата;
• создание новой резервной копии.

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

Возврат должен быть подготовлен до переноса

Самый простой возврат — снова указать DNS на старую площадку. Но он работает только если старая копия сохранена и после переключения не отстала по данным. Поэтому заранее определите момент, после которого возврат потребует обратной синхронизации, и кто принимает это решение.

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

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

Что читать дальше

• TTL и кеш DNS — почему разные пользователи видят переключение в разное время.
• Подключение домена к хостингу — проверки имени, виртуального хоста и HTTPS.
• Перенос сайта на другой VPS — отдельный сценарий с серверными командами и базой данных.
• Рекомендации Google по переносу сайта — что делать, если вместе с площадкой меняются URL.