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

Каждая минута недоступности сайта стоит денег. По оценке Gartner, час простоя IT-систем обходится бизнесу в среднем в 5 600 долларов за минуту, а интернет-магазин на 300 заказов в день теряет продажи даже за 20 минут тишины. Переезд на VPS выглядит как операция, где остановка неизбежна, но это не так. Схема, которую мы отработали на проектах разного масштаба, от лендингов до конфигураций, где нужна аренда сервера 1с, позволяет сменить хостинг незаметно для посетителей.

Что значит перенос без простоя и за счёт чего он возможен

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

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

Где обычно теряют время? На DNS. Записи кэшируются провайдерами на срок TTL, и при стандартных 24 часах часть аудитории ещё сутки ходит по прежнему адресу. Снижение TTL до 300 секунд за день до переезда решает проблему: после смены A-записи трафик уходит на VPS за пять минут.

Пример из практики. Интернет-магазин на WooCommerce с 400 заказами в сутки переезжал с shared-хостинга на VPS с 4 vCPU. Подготовка заняла два дня, само переключение - 6 минут, и за это время не потерялся ни один заказ: старая площадка работала в режиме только чтения, а новая приняла первые оплаты уже через четверть часа.

Схема параллельной работы старого хостинга и нового VPS

Как подготовить VPS к приёму сайта

Начните с точной копии окружения: те же версии PHP, СУБД и веб-сервера, что и на текущем хостинге. Различие даже в минорной версии PHP ломает плагины и темы, а искать причину после переезда сложнее, чем до него.

Текущие параметры смотрите командой php -v, через phpinfo() или в панели хостера. Отдельно проверьте расширения: mbstring, gd, intl и opcache часто отсутствуют в базовой установке. Соберите список заранее и поставьте всё сразу, чтобы потом не ловить белый экран вместо главной.

Минимальный набор для типового сайта на PHP выглядит так:
• Nginx или Apache той же ветки, что у прежнего хостера;
• PHP-FPM с нужными модулями;
• MySQL или MariaDB с совпадающей кодировкой и collation;
• Certbot для бесплатного SSL от Let's Encrypt;
• Firewall (ufw) с открытыми только портами 22, 80 и 443.

Про доступ забывать нельзя. SSH-ключи вместо паролей, отдельный пользователь без root-прав для деплоя, fail2ban против перебора. Исследование Sophos с honeypot-серверами показало: первые попытки подобрать пароль к SSH приходят меньше чем через час после появления машины в сети, а в отдельных регионах - через 52 секунды. Если собирать стек вручную не хочется, в ML Cloud можно взять VPS с готовым образом LEMP и сразу перейти к переносу данных.

Терминал с командой rsync для синхронизации файлов

Как перенести файлы и базу данных без потери изменений

Файлы переносятся в два прохода: первый полный, второй только с разницей перед самым переключением. База копируется дампом, а затем досинхронизируется повторным дампом в короткое окно read-only либо через бинарные логи.

Первый проход rsync запускайте в любое удобное время, он ничего не ломает. Для сайта на 20 ГБ с медиатекой передача по гигабитному каналу занимает 5-10 минут, а с shared-хостинга с ограничением скорости - до часа. Флаг --delete держите отключённым до финального шага, иначе случайно снесёте свежие загрузки пользователей.

Финальная синхронизация укладывается в четыре шага:
• Включить на действующем сайте режим только чтения (плагин maintenance или флаг в конфиге);
• Снять свежий дамп: mysqldump --single-transaction для InnoDB не блокирует таблицы;
• Прогнать rsync повторно, теперь уже с --delete;
• Импортировать дамп на VPS и сверить количество строк в ключевых таблицах.

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

Панель DNS с изменением A-записи

Как переключить домен и не потерять посетителей

Переключение сводится к замене A-записи домена на IP нового сервера при заранее пониженном TTL. Всё остальное - подготовка к тому, чтобы эти пять минут прошли гладко.

TTL снижайте минимум за 24 часа, лучше за 48. Кэш у провайдеров вроде Ростелекома и МТС иногда живёт дольше заявленного срока. За сутки до переезда убедитесь, что зона отдаёт новое значение: команда dig +noall +answer example.com покажет текущий TTL прямо в ответе.

С SSL есть нюанс: выпустить сертификат на VPS обычным способом не выйдет, пока домен смотрит на старый IP. Путей два. Можно перенести файлы сертификата и ключа вручную или использовать DNS-валидацию Certbot, которой не нужно, чтобы домен уже указывал на новую машину. Второй вариант надёжнее: сертификаты Let's Encrypt действуют 90 дней, и автопродление сразу заработает там, где ему и положено.

Что делать с посетителями, которые в переходный период попадают на прежний хостинг? Настройте там прокси: Nginx с директивой proxy_pass на IP VPS. Тогда даже запросы через закэшированный DNS уходят на новый сайт, и ни один заказ не осядет в устаревшей базе. Cloudflare решает ту же задачу проще: смена IP в его панели применяется мгновенно, независимо от TTL у провайдеров.

Что проверить после переезда и когда отключать старый сервер

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

Первые сутки после переключения проходите по чек-листу:
• Логи Nginx и PHP-FPM на ошибки 5xx;
• Отправка писем: SPF и DKIM должны содержать новый IP;
• Cron-задачи: бэкапы, обновление курсов, выгрузки в 1С;
• Вебхуки платёжных систем, привязанные к прежнему адресу.

Скорость - повод для радости или тревоги. Замерьте TTFB через PageSpeed Insights до и после миграции. Обычно переезд с виртуального хостинга на выделенную машину снижает время ответа с 800-1200 мс до 150-300 мс. Google в совместном исследовании с Deloitte показал, что ускорение мобильной страницы на 0,1 секунды поднимает конверсию розничных сайтов на 8 %, так что выигрыш прямой.

Мониторинг заводите сразу, а не после первого падения. UptimeRobot бесплатно опрашивает сайт раз в пять минут и шлёт уведомление в Telegram. Когда две недели прошли без сюрпризов, снимайте последний бэкап с прежнего сервера и отключайте его. Если проект сложнее одного сайта, например к нему привязана база 1С или несколько сервисов, инженеры ML Cloud помогут спланировать миграцию с учётом всех зависимостей.