Как перенести сайт без простоя

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

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

Составьте карту проекта: домены и DNS-зоны, файлы, базы, версии ОС и программ, PHP-модули, задания cron, очереди, почту, сертификаты, внешние хранилища и интеграции. Найдите данные вне основного каталога: загрузки, секреты, журналы и локальные кеши.

Зафиксируйте объём файлов и базы, скорость канала, нагрузку и допустимый простой. Проверьте лицензии и привязки к IP-адресу. Назначьте ответственных за инфраструктуру, приложение, DNS и бизнес-проверку. Подготовьте план отката с понятным условием запуска.

Разверните поддерживаемые версии веб-сервера, языка, СУБД и библиотек. Настройте пользователей, права, firewall, SSH, резервное копирование, мониторинг и время. Конфигурация должна быть совместима с приложением, но копировать устаревшие или небезопасные настройки не стоит.

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

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

Проверьте авторитетную зону, используемые A и AAAA-записи, поддомены и CDN. Не меняйте NS-серверы без необходимости: одновременные перенос зоны и смена адреса усложняют диагностику.

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

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

Откройте новый сайт через локальную запись hosts, технический домен или закрытый адрес. Это направляет тестировщика на новый сервер, пока посетители остаются на старом. Убедитесь, что приложение формирует ссылки для домена и не отправляет тестовые страницы в поисковый индекс.

Проверьте главную страницу, авторизацию, поиск, формы, загрузку файлов, административную часть и критичные бизнес-сценарии. Для магазина пройдите корзину, доставку и тестовую оплату. Отдельно проверьте редиректы, сертификат, заголовки, почту, задания cron, API, права файлов и журналы ошибок.

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

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

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

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

Контролируйте доступность, время ответа, ошибки HTTP, загрузку CPU и RAM, место на диске, соединения с базой и очереди. Сравните трафик со старым сервером, чтобы увидеть остаточные обращения. Проверьте сертификаты, почту, резервное копирование и поступление данных от внешних систем.

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

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