Перенос сайта на новый хостинг без простоя: пошаговая инструкция

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

Перенос сайта на новый хостинг звучит как операция на 2 часа, и для статической визитки это правда. Для интернет-магазина с реальным трафиком и приёмом заявок ситуация другая. Здесь любое окно простоя стоит денег: за час даунтайма в обед интернет-магазин на 50 заказов в день теряет 5-7 заявок и кусок индексации. Эта статья про то, как переехать без видимого простоя, с минимальным риском и контрольным списком, по которому можно работать.

В моей практике переездов было больше 80, из них половина с одного российского shared-хостинга на другой, остальные с VPS на VPS или с международного на российский. Принципы одинаковые. Разница только в том, какие конкретно команды и интерфейсы вы используете. Ниже общий рецепт, который масштабируется на любой проект до 50 ГБ файлов и 5 ГБ базы.

Что собрать ДО старта переноса

Главная ошибка торопливого переноса: начать с команды tar czf site.tar.gz . без сбора артефактов. Через два часа окажется, что на новом хостинге другой PHP, нет нужного расширения и забытый sendmail. Чтобы не править ночью, сделайте опись.

Пять обязательных пунктов перед стартом:

1. Версия PHP и список расширений на старом хостинге. Команда php -v && php -m. Если на новом хостинге нет, например, intl или imagick, заявку в техподдержку отправляют сейчас, а не в момент переезда.
2. Версия MySQL/MariaDB и режим SQL. Это влияет на совместимость дампа. Команды mysql --version и SELECT @@sql_mode;. Если на старом был STRICT_TRANS_TABLES, на новом тоже должен быть, иначе валидация полей поедет.
3. Список cron-задач. crontab -l для текущего пользователя. Скопировать в текстовый файл, чтобы не забыть включить на новом сервере.
4. Структура почты на домене. Если корпоративные ящики info@, sales@ обслуживаются на старом хостинге, нужно либо переносить ящики, либо перевести почту в Яндекс 360 или Mail для бизнеса заранее.
5. DNS-записи. Полный дамп зоны: A, AAAA, MX, TXT (SPF, DKIM, DMARC), CNAME. Команда dig site.ru ANY +noall +answer или экспорт зоны в панели регистратора.

Дополнительно проверьте размер базы и файлов: du -sh ~/public_html и du -sh ~/db_backup.sql. Это нужно, чтобы понять, сколько займёт перенос. На приличном канале гигабайт переезжает 2-5 минут, но если это магазин с фотками на 30 ГБ, нужно планировать заранее, а не запускать scp за час до окончания рабочего дня.

Чек-лист совместимости

Параметр	Старый хостинг	Новый хостинг	Совпадает?
PHP	8.1	8.2	Близко, проверить deprecated
memory_limit	256M	256M	Да
Расширения PHP	curl, gd, mbstring, intl, imagick	curl, gd, mbstring, intl	Не хватает imagick
MySQL	8.0	8.0	Да
Лимит писем в час	200	100	Меньше, риск с рассылками
SSH	Да	Да	Да

Эту таблицу заполняют руками за 30 минут. Если по какому-то параметру стоит «не хватает» или «меньше», решение либо до переноса (попросить добавить), либо заложить в план миграции (сменить логику отправки писем, переключить obrabotku картинок с imagick на gd).

Поднять зеркало на новом хостинге и проверить через hosts

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

Перенос файлов через rsync или scp в зависимости от того, что доступно:

# С rsync (быстрее, инкрементально)
rsync -avz --progress 
  -e "ssh -p 22" 
  /home/user/old-site/ 
  newuser@new-host.ru:/home/newuser/site/

# Без rsync, через tar и pipe
ssh oldhost 'cd /home/user/old-site && tar czf - .' | 
ssh newhost 'cd /home/newuser/site && tar xzf -'

Перенос базы через mysqldump:

# На старом сервере
mysqldump -u olduser -p --single-transaction --routines --triggers 
  oldbase > /tmp/dump.sql

# Перенос файла
scp /tmp/dump.sql newuser@new-host.ru:/tmp/

# На новом сервере
mysql -u newuser -p newbase < /tmp/dump.sql

Флаг --single-transaction важен для InnoDB: дамп снимается консистентно без блокировки таблиц. Без него на работающем магазине можно поймать половинчатый снимок, где заказ в orders есть, а позиции в order_items нет.

После переноса меняем конфиг сайта на новые креды БД. Для WordPress это wp-config.php:

define('DB_HOST', 'localhost');
define('DB_NAME', 'newbase');
define('DB_USER', 'newuser');
define('DB_PASSWORD', 'newpassword');

Для Битрикс это bitrix/.settings.php (новая версия) или bitrix/php_interface/dbconn.php (старая). Для OpenCart это config.php и admin/config.php. Не забываем поменять $_SERVER['HTTP_HOST'] или соответствующий путь в обоих файлах OpenCart.

Проверка через hosts

Теперь самое важное. Чтобы проверить, что сайт на новом сервере работает, не дожидаясь переключения DNS, добавьте в файл hosts на своём компьютере одну строку:

# Windows: C:WindowsSystem32driversetchosts
# Linux/Mac: /etc/hosts
NEW.IP.AD.DR  site.ru www.site.ru

Закройте все вкладки браузера с этим сайтом, очистите кеш DNS:

# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache
# Linux
sudo systemctl restart systemd-resolved

Откройте сайт. Теперь для вас он идёт на новый хостинг, а для всех остальных на старый. Прогуляйтесь по сайту, проверьте формы (на тестовом email, не на реальном), посмотрите личный кабинет, оформите тестовый заказ. Если что-то не работает, у вас есть сколько угодно времени на починку, потому что реальные пользователи всё ещё на старом сервере.

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

Двойная запись и синхронизация БД на момент переключения DNS

Самый коварный момент переезда: на момент смены NS часть пользователей уже видит новый сервер, часть ещё видит старый. Если за это окно (от часа до 48 часов) на сайт пришёл заказ или сообщение через форму, оно может уйти в одну из двух баз. После переключения вторая база останется с заказом, который никто не увидит.

Вариантов решения три, по убыванию красоты и сложности.

Вариант 1: окно технических работ. Самый простой. Вешаете на сайте заглушку «ведутся технические работы, заказы временно не принимаем», оставляете контактный телефон, ждёте сходимости DNS (12-24 часа). Подходит для b2b-сайтов с малым потоком, для информационных проектов. Не подходит для магазина в сезон.

Вариант 2: режим только-чтение на момент переключения. Хитрее. На старом сайте отключаете формы и оформление заказов (выводите сообщение «приём заявок временно перенесён, звоните»), а сами в этот момент уже получаете заказы по телефону или мессенджеру. Через 24-48 часов, когда трафик ушёл на новый сервер, включаете формы там. Окно потерянных заявок: близко к нулю при условии, что менеджер успевает.

Вариант 3: репликация на момент переключения. Самый чистый. Настраиваете MySQL replication со старой базы на новую перед сменой NS. Все INSERT и UPDATE на старом сервере мгновенно применяются на новом. После переключения часть трафика идёт на новый, который пишет в свою базу, часть на старый, который пишет в свою и реплицирует на новый. Окно потерянных заявок: ноль. Но настройка требует доступа к my.cnf, бинлогов и опыта. На shared-хостинге обычно недоступно.

Для большинства сайтов малого бизнеса я использую вариант 2. Перед переключением вешаю в шапку плашку «приём заявок только по телефону +7 ХХХ-ХХ-ХХ», форма становится неактивной, переключаю DNS, жду сходимости, возвращаю формы на новом сервере. Простоя в обычном смысле нет, есть лишь окно с ограниченной функциональностью на 12-24 часа.

Само переключение DNS

Перед переключением снижаем TTL у NS-записей до 300 секунд (5 минут) за сутки до миграции. Так после смены IP клиенты подхватят новый адрес быстрее.

# Было:
site.ru.   A   86400   1.2.3.4
# Меняем за сутки на:
site.ru.   A   300     1.2.3.4
# В момент переключения:
site.ru.   A   300     5.6.7.8
# После сходимости (через сутки) возвращаем:
site.ru.   A   86400   5.6.7.8

Если используете Cloudflare как DNS-провайдер, изменения применяются мгновенно, можно пропустить шаг с снижением TTL. Если у вас зона у регистратора Reg.ru или Beget, TTL влияет напрямую.

После смены NS проверяем сходимость. Через 30 минут проверяем с разных регионов:

dig @8.8.8.8 site.ru +short          # Google DNS
dig @77.88.8.8 site.ru +short        # Yandex DNS
dig @1.1.1.1 site.ru +short          # Cloudflare DNS

# Веб-сервис для проверки сходимости в десятках точек
# https://dnschecker.org/ , открыть в браузере

Когда все три DNS показывают новый IP, переключение прошло. На сходимость в 99% точек уходит 1-6 часов при TTL 300, до 24 часов при TTL 3600.

Что меняется в .htaccess, php.ini, ssl и как это перепроверить

Каждый хостинг имеет свои особенности. Что точно нужно проверить после переезда:

.htaccess. Часть директив зависит от модулей Apache. Если на старом был mod_rewrite, а на новом нет (редко, но бывает на дешёвых тарифах), все красивые URL перестанут работать. Проверка через curl -I https://site.ru/contacts/ должна дать 200, а не 404.

Также на shared нельзя использовать директивы уровня сервера: <LocationMatch>, <VirtualHost>, RewriteOptions InheritDown, Options +ExecCGI (часто запрещено). Если такие директивы есть в .htaccess, Apache отдаст 500 Internal Server Error сразу для всех маршрутов. Проверьте .htaccess глазами после переноса, удалите запрещённые директивы.

php.ini. Не все хостинги дают свою php.ini, многие используют .user.ini для перекрытия. Параметры, которые обычно нужно скопировать руками:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_vars = 5000

После загрузки .user.ini подождите 5 минут и проверьте через phpinfo() или скрипт:

<?php
echo "memory_limit: " . ini_get('memory_limit') . "n";
echo "max_execution_time: " . ini_get('max_execution_time') . "n";
echo "post_max_size: " . ini_get('post_max_size') . "n";

SSL. Если на старом был платный сертификат, на новом обычно проще выпустить заново через Let’s Encrypt (бесплатно, автоматически в большинстве панелей). Проверка после установки:

curl -I https://site.ru/                              # должен дать 200
echo | openssl s_client -connect site.ru:443 -servername site.ru 2>/dev/null | 
  openssl x509 -noout -dates                          # покажет сроки

Не забудьте про принудительный редирект HTTP→HTTPS в .htaccess или конфигурации nginx:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Smtp. Если сайт отправлял письма через локальный sendmail, на новом сервере он тоже должен быть. Проверка which sendmail. Если отправка шла через внешний SMTP (Mailgun, Yandex Postmaster), скопируйте креды и проверьте, что новый IP не в чёрных списках:

# Простая проверка отправки через PHP
php -r 'mail("test@gmail.com","test","body","From: noreply@site.ru");'

Если письмо ушло, но не пришло, скорее всего упало в спам из-за SPF/DKIM. Проверьте, что DNS-записи SPF и DKIM указывают на новый сервер или на ваш SMTP-релей.

Чек-лист после переезда

После переключения DNS прохожу по списку. Это занимает 30-60 минут, но ловит 95% типичных проблем.

• [ ] Главная отдаёт 200 через curl -sI https://site.ru/.
• [ ] Внутренние страницы отдают 200, а не 404 (проверить 5-10 случайных URL).
• [ ] HTTP редиректит на HTTPS через 301.
• [ ] www-версия редиректит на без-www (или наоборот, как раньше).
• [ ] Картинки в HTML открываются (нет 404 на картинках).
• [ ] CSS и JS отдают правильный Content-Type (text/css, application/javascript).
• [ ] Форма обратной связи реально отправляет письмо. Не только показывает «спасибо».
• [ ] Письмо приходит на корпоративный email, не падает в спам.
• [ ] Если есть личный кабинет, тестовый пользователь может войти.
• [ ] Если есть оплата, тестовый платёж проходит.
• [ ] Я.Метрика показывает посещения с продакшна за последний час.
• [ ] Корпоративная почта info@site.ru принимает входящие.
• [ ] Корпоративная почта info@site.ru отправляет, и письмо приходит на gmail/yandex/mail.
• [ ] Cron-задачи перенесены и запускаются (проверить через tail -f /var/log/cron или вывод задачи).
• [ ] Бэкапы настроены на новом сервере.
• [ ] В Я.Вебмастер и GSC индексация продолжается, нет роста 5xx-ошибок.
• [ ] Скорость загрузки не упала: проверка через PageSpeed Insights, сравнение с замером до переезда.

Что обычно ловится через 2-3 дня после переезда

• Недоставленные письма. Появятся в виде жалоб клиентов «не получил подтверждение заказа» через сутки-двое. Проверить логи отправки, проверить попадание в спам, при необходимости настроить SPF/DKIM/DMARC.
• Поломанные сторонние интеграции. Webhook от платёжки, обратные вызовы от CRM, выгрузки из 1С. Если IP сервера изменился, у некоторых сервисов в whitelist нужно прописать новый.
• Кеш DNS у части провайдеров. У ростелекома и некоторых региональных провайдеров TTL игнорируется, кеш живёт до 48 часов. Решается ожиданием, ничего не делать.
• Резкие колебания позиций в поиске на 1-3 дня. Нормальная реакция Я.Вебмастера на смену IP. Если позиции не вернулись через неделю, есть основания смотреть глубже (проверить редиректы, robots, sitemap).

Несколько типовых сценариев и сроков

Визитка на WordPress, 200 МБ файлов, 50 МБ база. Перенос: 2 часа на копирование, 1 час на проверку, переключение DNS с TTL 300, ноль простоя. Сложность низкая, цена работ 5-10 тысяч.

Корпоративный сайт на Битрикс, 5 ГБ файлов, 1 ГБ база, лицензия. Перенос: полдня на копирование, 2 часа на конфигурацию .settings.php и dbconn.php, переписка с лицензией. Окно работ: 4-8 часов с заглушкой. Сложность средняя, 25-40 тысяч.

Магазин на OpenCart, 30 ГБ картинок, 3 ГБ база, 50 заказов в день. Перенос: 6-12 часов на копирование инкрементально, плюс docelowe окно с заглушкой на 1-2 часа в наименее загруженное время суток. Сложность высокая, 50-80 тысяч.

Внутренний портал на 1С-Битрикс с интеграциями. Перенос: 1-2 рабочих дня, обязательно пробный переезд на тестовый домен сначала. Сложность очень высокая, от 80 тысяч.

Когда переносить нельзя или не сейчас

Не каждый момент подходит для миграции. Не переносите:

• В ноябре-декабре, если у вас интернет-магазин. Сезон, любая ошибка стоит дороже обычного.
• Накануне рассылки или промо-акции. Если в течение недели после переезда планируется наплыв трафика, а вы не успели мониторинг настроить, поймаете двойной стресс.
• В день, когда нет связи с подрядчиком, который за переезд отвечает. Очевидно, но именно этот пункт регулярно нарушают, потому что «уже договорились на пятницу».
• Если на старом хостинге неоплаченный долг. Хостер может отрубить доступ к файлам в любой момент, и вы останетесь без последнего бэкапа.

CTA

Если стоит задача переехать без простоя и вам нужен подрядчик, который пройдёт по чек-листу выше и закроет все хвосты, напишите через форму на /#contact. Я делаю миграции под ключ или сопровождением (вы сами с админом, я подсказываю и принимаю результат). Стоимость и пакеты лежат на /#pricing. Другие материалы по теме инфраструктуры и поддержки сайта собраны в рубрике /blog/category/support/.

Частые вопросы

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

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

Что делать с заявками во время переключения

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

Сколько занимает распространение DNS

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

Что проверить после переезда

Сертификат и работу по https, отправку почты с сайта, права на файлы, работу планировщика, версию PHP и правила в конфигурационных файлах. Каждый пункт ломается по отдельности.