Перенос сайта на новый VPS без простоя

MAATRIX

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

Главный принцип: сначала копия, потом переключение

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

Проверить копию по IP до переключения DNS проще всего, прописав домен в локальный hosts только на своей машине:

# Linux/macOS: /etc/hosts, Windows: C:\Windows\System32\drivers\etc\hosts
НОВЫЙ_IP  example.com www.example.com

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

Готовим новый сервер

На чистом VPS ставим тот же стек, что был на старом: веб-сервер, PHP или другой рантайм, базу данных. Версии желательно подобрать те же самые — расхождение мажорных версий PHP или MySQL часто и есть причина «на старом работало, на новом нет». Проверьте, что версии совпадают, до переноса данных.

# что стоит на старом сервере
php -v; nginx -v; mysql --version
# ставим аналогичный набор на новом (пример для Debian/Ubuntu)
apt update && apt install nginx php-fpm php-mysql mariadb-server -y

Заранее откройте нужные порты фаерволом (80 и 443), настройте пользователя и каталоги сайта. Пусть новый сервер будет готов принять данные — тогда сама миграция сведётся к копированию файлов и импорту базы.

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

Переносим файлы и базу данных

Файлы удобнее всего синхронизировать через rsync — он копирует только изменившееся и легко запускается повторно. Базу выгружаем дампом и импортируем на новом сервере.

# файлы сайта со старого сервера на новый
rsync -avz --delete /var/www/example.com/ root@НОВЫЙ_IP:/var/www/example.com/
# дамп базы на старом
mysqldump -u root -p --single-transaction mydb > mydb.sql
# импорт на новом
mysql -u root -p mydb < mydb.sql

Флаг --single-transaction снимает дамп без блокировки таблиц — сайт на старом сервере продолжает работать. После импорта поправьте конфиг сайта: пути, реквизиты подключения к базе, при необходимости адрес сайта в настройках CMS. Именно на этом этапе пригодится проверка через hosts из первой секции.

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

Снижаем TTL заранее

Ключ к переключению без простоя — заранее уменьшить TTL DNS-записи. TTL говорит, сколько провайдеры и браузеры кэшируют старый IP. Если он равен 86400 (сутки), часть посетителей будет попадать на старый сервер ещё день после смены записи. Уменьшите TTL за сутки-двое до переезда:

# было
example.com.  86400  IN  A  СТАРЫЙ_IP
# ставим за день до переезда
example.com.  300    IN  A  СТАРЫЙ_IP

Значение 300 (5 минут) означает, что после смены A-записи мир переключится на новый IP почти мгновенно. Сразу после успешного переезда TTL можно вернуть к большому значению. Этот приём и превращает «переключение на сутки» в «переключение за пять минут».

Момент переключения

Когда копия проверена и TTL снижен, наступает сам переезд. Чтобы не потерять данные, накопившиеся на старом сервере за время подготовки (новые заказы, комментарии, загрузки), делаем финальную досинхронизацию прямо перед сменой DNS:

# финальный rsync файлов
rsync -avz --delete /var/www/example.com/ root@НОВЫЙ_IP:/var/www/example.com/
# свежий дамп и импорт базы
mysqldump -u root -p --single-transaction mydb | ssh root@НОВЫЙ_IP 'mysql -u root -пПАРОЛЬ mydb'

Сразу после этого меняете A-запись домена на новый IP. Благодаря низкому TTL посетители начнут попадать на новый сервер в течение минут. Старый сервер не выключайте ещё сутки-двое — на него будут заходить те, у кого запись ещё в кэше, и обрыва они не заметят.

Не забываем про SSL и почту

Частая причина «сайт открылся, но с ошибкой безопасности» — забытый сертификат. Выпустите его на новом сервере заранее. Let's Encrypt умеет проверять владение доменом до переключения DNS через DNS-челлендж, но проще выпустить сертификат сразу после смены записи:

certbot --nginx -d example.com -d www.example.com

Отдельно проверьте почту: если MX-записи указывают на тот же сервер, что и сайт, их тоже нужно перенести и не потерять письма. Если почта на отдельном сервисе — она переезда сайта не касается, MX-записи не трогайте. Это частая ловушка: люди меняют все DNS-записи скопом и случайно уводят почту в никуда.

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

Проверка после переезда и профилактика

После переключения пройдитесь по чек-листу: сайт открывается по домену и по https, формы отправляются, админка работает, в логах нет всплеска ошибок. Полезно последить за access.log нового сервера — по нему видно, что трафик реально переехал.

tail -f /var/log/nginx/access.log
# проверить, что домен резолвится в новый IP
dig +short example.com

Чтобы будущие переезды были ещё проще, держите инфраструктуру в порядке: конфиги — под контролем версий, регулярные бэкапы базы и файлов, документированный список DNS-записей. Тогда следующий переезд займёт не вечер, а полчаса. Удобно, когда новый сервер можно поднять за минуты и в нужной локации — у MAATRIX есть VPS в RU, US и UK с оплатой из России картой или криптой, что снимает лишнюю возню на этапе подготовки площадки.

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