Переезд сайта на российский хостинг без простоя — пошагово

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

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

Почему переезд вообще роняет сайты

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

За неделю до: снижаем TTL DNS

TTL (time to live) — сколько провайдеры и браузеры кэшируют DNS-запись. Если у A-записи стоят стандартные 86400 секунд (сутки), после переключения часть посетителей ещё день будет попадать на старый IP. Поэтому за 24-48 часов до переезда снижаем TTL до 300 секунд (5 минут).

  • Заходим в панель DNS — у регистратора домена или в облаке.
  • Для A/AAAA и CNAME основного домена ставим TTL = 300.
  • Ждём, пока старое значение TTL истечёт, — только после этого продолжаем.

Этот шаг — единственный, который нельзя ускорить. Планируйте его заранее.

Полный бэкап: файлы плюс база

Снимаем две копии: файлы сайта и дамп базы данных. Файлы — архивом, базу — через mysqldump с флагом консистентности.

tar czf site.tar.gz /var/www/site
mysqldump -u user -p --single-transaction db_name > dump.sql

Флаг --single-transaction снимает согласованный слепок InnoDB без остановки сайта. Копии сразу переносим на новый сервер (scp/rsync) и сверяем контрольные суммы.

Поднимаем копию и тестируем по hosts

На новом сервере разворачиваем идентичное окружение: та же версия PHP, расширения, веб-сервер, права на файлы. Импортируем базу, распаковываем файлы. Сайт по-прежнему живёт на старом IP — ничего не переключаем.

Проверить новый сервер под «боевым» доменом, не трогая DNS, помогает файл hosts на вашем компьютере. Добавляем строку с новым IP:

203.0.113.10   internet10k.com www.internet10k.com

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

Переключение DNS и параллельная работа

Когда тест пройден — меняем A-запись на новый IP. Благодаря TTL = 300 переключение расходится за 5-10 минут. Но старый сервер не выключаем ещё 24-48 часов: часть кэшей обновится с задержкой, и эти посетители должны попадать на рабочий сайт.

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

Грабли и план отката

  • Забыли про почту. MX-записи и SPF/DKIM живут отдельно — переезд веб-сервера может оставить почту на старом хосте. Проверяйте отдельно.
  • Захардкоженный старый IP. В конфигах, вебхуках и интеграциях иногда прописан IP, а не домен. Ищем и меняем.
  • Нет отката. Пока TTL низкий и старый сервер жив, откат — это просто вернуть прежний IP в A-запись. Держите это окно открытым сутки-двое.

Вывод

Переезд без простоя — это не удача, а последовательность: снизить TTL, снять консистентный бэкап, поднять и протестировать копию по hosts, переключить DNS и подержать старый сервер в параллели с планом отката. Каждый шаг убирает конкретный риск. Если не хотите проверять всё это на живом трафике — поможем перенести сайт на российский хостинг без даунтайма: от аудита текущего окружения до переключения DNS и контроля первых суток.

Перенос инфраструктуры в облако
Услуга по теме — обсудим ваш проект.