Переезд сайта на российский хостинг без простоя — пошагово
Даунтайм при переезде на новый хостинг — не неизбежность, а следствие ошибок. Пошаговый план миграции без простоя: снижение 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 и контроля первых суток.