Переезд с шаред-хостинга на VPS без простоя: полный план

MAATRIX

Сайт перерос тариф на шаред-хостинге — не хватает ресурсов, нельзя поставить нужную версию PHP, панель ограничивает cron и доступ по SSH. Переезд на VPS решает эти проблемы, но пугает риском простоя: боитесь, что в момент переключения посетители увидят ошибку, а магазин потеряет заказы. Ниже — пошаговый план, который сводит простой к нулю, если соблюдать порядок действий и не торопить последний шаг.

Чем переезд с шаред-хостинга отличается от VPS

Инструкции «просто перенеси сайт на новый сервер» обычно писаны для переезда между двумя VPS, где на обеих сторонах есть root и SSH. С шаред-хостингом всё сложнее, и это стоит признать сразу, а не узнавать в процессе.

Во-первых, доступ. Часть панелей (ISPmanager, cPanel, Plesk) дают SSH, но часто урезанный — без прав на sudo, иногда вообще без shell, только FTP/SFTP и веб-интерфейс. Тогда rsync по SSH недоступен, и файлы придётся тянуть через SFTP-клиент или через встроенный экспорт файлового менеджера панели — это медленнее и без удобного --delete для докачки только изменений.

Во-вторых, веб-сервер. На шаред-хостинге почти всегда Apache с .htaccess — правила mod_rewrite, ограничения доступа, настройки кеша прописаны именно там. На VPS вы, скорее всего, поставите nginx (быстрее, экономнее по памяти), а .htaccess в nginx не работает вообще — его директивы нужно вручную переписать в блоки location и try_files. Это отдельная работа, и именно здесь чаще всего теряют функциональность при переезде: забытое правило редиректа, забытая защита каталога с загрузками.

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

Честно: часть этой работы — не копипаста команд, а ручная сверка конфигурации. Если сайт сложный (много плагинов, кастомный .htaccess, специфичные cron-задачи в панели), закладывайте на подготовку не один вечер, а несколько дней тестов.

Готовим новый VPS заранее

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

Сначала выясните, что именно стоит на шаред-хостинге:

php -v
php -m                # список установленных модулей PHP
mysql --version        # или через phpMyAdmin -> "О программе"

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

На VPS ставим совместимый стек. Пример для Ubuntu 24.04 с LEMP (nginx + PHP-FPM + MySQL):

apt update && apt install nginx mariadb-server -y
apt install php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip -y

Список модулей PHP сверьте с тем, что вывела команда php -m на старом хостинге — если чего-то не хватает, часть функций CMS (генерация превью картинок, импорт XML, работа с архивами) может тихо отвалиться без явной ошибки в логах.

Создайте на VPS структуру каталогов сайта, пользователя, базу данных и виртуальный хост nginx — со всеми доменами и алиасами, которые были в конфиге Apache. Здесь и происходит перевод правил .htaccess в nginx. Частый случай — ЧПУ (человекопонятные URL) для CMS:

# было в .htaccess (Apache)
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]

# стало в nginx, блок server { ... }
location / {
    try_files $uri $uri/ /index.php?$args;
}

Если в .htaccess были ограничения доступа (deny from all для служебных папок), пароль через .htpasswd или запреты по IP — их тоже нужно перенести руками в конфиг nginx, автоматической конвертации, которой можно доверять на 100%, не существует.

Риск этого шага: несовпадение версии PHP или отсутствующий модуль вылезет не сразу, а на конкретной странице сайта — например, при загрузке изображения или выгрузке отчёта. Проверяйте не только главную страницу, а ключевые функции (форма заказа, админка, поиск) ещё на этапе теста по IP, до переключения DNS.

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

Пока старый хостинг работает и отдаёт сайт живым посетителям, копируем данные на VPS.

Файлы. Если панель дала SSH — используете rsync, он копирует только изменившееся и безопасно перезапускается:

rsync -avz -e ssh username@shared-host.example.com:~/public_html/ /var/www/example.com/

Если SSH нет — только SFTP или встроенный «Экспорт сайта» в панели (обычно архивирует public_html в .zip/.tar.gz, который потом скачиваете и разворачиваете на VPS). Это медленнее и не докачивает только дельту — для сайта с гигабайтами загрузок первая полная выгрузка может занять часы, закладывайте время заранее, а не в последний вечер.

База данных. Через SSH — классический mysqldump:

mysqldump -u dbuser -p --single-transaction dbname > dbname.sql
scp dbname.sql root@НОВЫЙ_IP:/tmp/
# на новом сервере
mysql -u dbuser -p dbname < /tmp/dbname.sql

Флаг --single-transaction снимает дамп без блокировки таблиц InnoDB — сайт на старом хостинге продолжает принимать запросы. Если shell недоступен — экспорт делаете через phpMyAdmin («Экспорт» → формат SQL, для больших баз выбирайте сжатие gzip, у панелей часто есть лимит на размер загружаемого файла при импорте — тогда дамп бьют на части или заливают через mysql из консоли, если она в панели есть).

После импорта обязательно поправьте в конфиге CMS: адрес базы (обычно localhost меняется на 127.0.0.1 или наоборот, в зависимости от сокета), учётные данные, а для некоторых CMS — и сохранённый в базе URL сайта (WordPress хранит его в таблице wp_options, Bitrix — в .settings.php и таблицах модулей).

Риск: дамп базы, снятый в середине дня без --single-transaction (или снятый через панель без учёта активных транзакций), может получиться рассогласованным — часть связанных таблиц окажется в разных «временных срезах». Для интернет-магазина это может значить заказ без товарных позиций. Проверяйте наличие --single-transaction для InnoDB или используйте экспорт панели в моменты минимальной нагрузки.

Тестируем копию по IP без переключения DNS

Не переключайте домен сразу после переноса — сначала убедитесь, что копия работает идентично оригиналу. Самый безопасный способ — прописать домен на свою локальную машину, не трогая реальный DNS:

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

Теперь только ваш браузер обращается к новому VPS, а весь остальной мир по-прежнему видит старый хостинг. Пройдитесь по сайту как обычный посетитель и как администратор: главная страница, карточка товара, оформление заказа (без реальной оплаты), форма обратной связи, вход в админку, поиск, загрузка файла. Отдельно проверьте https — сертификат на новом сервере нужно выпустить заранее:

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

Certbot по умолчанию проверяет владение доменом через HTTP-запрос на порт 80 того же домена, а домен ещё указывает на старый хостинг — из-за этого автоматический выпуск сертификата в этот момент может не пройти. Рабочий вариант — DNS-challenge (не требует, чтобы домен уже указывал на новый сервер) или подготовка сертификата не для конечного публичного домена, а временный self-signed для внутреннего теста, а боевой сертификат выпустить сразу после переключения DNS, в первые же минуты.

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

TTL, финальная синхронизация и заморозка записи

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

# было
example.com.  86400  IN  A  IP_ШАРЕД_ХОСТИНГА
# ставим заранее, за 1-2 дня
example.com.  300    IN  A  IP_ШАРЕД_ХОСТИНГА

300 секунд (5 минут) — комфортное значение: после реальной смены A-записи мир переключается почти мгновенно. После стабилизации переезда TTL можно вернуть к обычным значениям.

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

Два честных варианта, и оба с компромиссом:

• Заморозка записи на короткое окно. Перед финальным переключением на 15–30 минут включаете на старом хостинге режим обслуживания (maintenance mode в CMS, статичная заглушка «идут технические работы», или временная блокировка на уровне .htaccess) — новые заказы и правки не принимаются, зато данные гарантированно консистентны в момент финального дампа. Минус — те самые 15–30 минут посетитель не может оформить заказ (хотя сайт при этом не «падает», а показывает понятное сообщение — это не то же самое, что ошибка 500 при неаккуратном DNS-переезде).
• Без заморозки, только финальная досинхронизация. Снимаете дамп прямо перед переключением DNS и импортируете дельту на VPS. Плюс — ноль видимых ограничений для посетителя. Минус — если между финальным дампом и моментом, когда весь трафик реально перешёл на VPS (а это не мгновенно даже при TTL 300, у части провайдеров кеш живёт дольше документированного), на старом сервере успеет появиться ещё один заказ — и он не попадёт в базу на VPS.

Для сайта-визитки или блога вторым вариантом можно пренебречь просчётом — риск не в деньгах. Для интернет-магазина или сайта с оплатой честнее закладывать короткое окно заморозки: 15–30 минут технических работ ночью или в наименее загруженный час выглядят надёжнее, чем шанс потерять оплаченный заказ.

Переключение, план отката и что делать после

Когда копия проверена, TTL снижен, а данные синхронизированы (с заморозкой или без) — переключаете A-запись на IP нового VPS.

example.com.  300  IN  A  IP_НОВОГО_VPS

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

# откатываем A-запись обратно на старый хостинг
example.com.  300  IN  A  IP_ШАРЕД_ХОСТИНГА

Именно низкий TTL, снижённый заранее, делает откат таким же быстрым, как и само переключение — минуты, а не сутки. Это и есть главная причина не забывать про TTL: он одинаково выручает что при удачном переезде, что при откате.

После переключения проверьте вручную (не полагаясь на «наверное, всё ок»):

dig +short example.com
curl -I https://example.com
tail -f /var/log/nginx/access.log

Убедитесь, что домен резолвится в новый IP, сайт отвечает 200/301 (а не 500), в логах нет всплеска ошибок 404 на статику (частый симптом забытого правила в конвертации .htaccess → nginx). Проверьте оба варианта адреса — с www и без, по http и по https, редиректы должны вести на канонический вариант так же, как раньше.

Через несколько дней стабильной работы на VPS, когда убедились, что новые заказы и правки действительно попадают в базу нового сервера, можно отключать шаред-хостинг. Не раньше — это ваша страховка на случай отложенной проблемы, которая не проявилась в первые часы.

Похожие по теме материалы блога: если переезд идёт между двумя VPS (без сложностей шаред-хостинга с .htaccess и урезанным SSH), пригодится более общий разбор в статье «Перенос сайта на новый VPS без простоя». Отдельно про перенос базы данных между серверами и частые ошибки дампа — в статье «Миграция базы данных между серверами». Про базовую настройку самого VPS перед переездом — в чек-листе «Первый день на новом VPS», а про установку веб-сервера и PHP с нуля — в статье «Установка веб-сервера LEMP с нуля».

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