Переезд с виртуального хостинга на VPS откладывают до последнего: страшно сломать сайт, потерять заказы, остаться без поддержки хостера. На деле правильно организованный перенос занимает один вечер и не даёт ни минуты простоя — потому что новый сервер полностью готовится и проверяется, пока старый продолжает работать. Ниже — как это сделать, с командами и чек-листом.
Когда пора уходить с хостинга
- Сайт периодически «задумывается» без видимой причины. На хостинге вы делите процессор и диск с сотнями соседей, и чужой всплеск нагрузки становится вашей проблемой.
- Провайдер присылает предупреждения о превышении лимита процессов, CPU или нагрузки на базу. Это прямой сигнал: следующим шагом будет отключение.
- Не хватает версии PHP, расширения, библиотеки. Набор на хостинге фиксирован, и просьба что-то доставить обычно упирается в отказ.
- Нужен фоновый процесс — очередь задач, бот, регулярная выгрузка на маркетплейс, WebSocket-сервер. Хостинги такое запрещают или ограничивают временем выполнения.
- Нужен контроль: свой firewall, нестандартный веб-сервер, Docker, отдельная база с большим буфером.
Если узнали хотя бы два пункта — переезжайте, не дожидаясь третьего.
Что меняется: свобода и ответственность
На хостинге обновления, безопасность и работоспособность окружения — забота провайдера. На VPS это ваша зона. Минимум, который придётся освоить: подключение по SSH, обновления системы, настройка веб-сервера и базы, резервное копирование. Это несколько часов на старте и полчаса в месяц потом.
Если консоль не для вас, ставьте панель управления — ISPmanager, HestiaCP, aaPanel. Она закрывает рутину через веб-интерфейс: сайты, SSL, почта, бэкапы. Панели нужен гигабайт памяти, поэтому под неё берите тариф от Start; как посчитать ресурсы под ваш сайт с панелью или без — в статье «Как выбрать тариф VPS».
Шаг 0. Подготовка за 2–3 дня до переезда
Снизьте TTL у DNS-записей
TTL — время, на которое DNS-серверы по миру запоминают IP вашего сайта. Обычно стоит 3600 секунд или сутки. За два дня до переезда поставьте A-записи домена TTL 300 секунд: тогда после смены адреса пользователи перейдут на новый сервер за пять минут, а не за сутки.
Снимите полную копию
Файлы сайта — через FTP, SFTP или менеджер файлов хостинга, архивом. База — через phpMyAdmin (экспорт в SQL) или командой хостера, если есть SSH:
mysqldump -u USER -p DBNAME | gzip > site.sql.gz
Обязательно проверьте, что копия разворачивается, а не просто существует: распакуйте архив, откройте дамп — в нём должны быть таблицы, а не сообщение об ошибке.
Выпишите всё, что настроено вне файлов
Cron-задачи, почтовые ящики на домене, редиректы в панели хостинга, SSL-сертификат, переменные окружения. Именно это забывают перенести чаще всего.
Шаг 1. Выбор и заказ сервера
Для сайта на WordPress, Joomla, OpenCart или Bitrix с базой данных берите Start (2 ядра, 2 ГБ, $10): гигабайт Lite уходит на систему, PHP и MySQL, кэшу места не остаётся. Для магазина с тысячами товаров — Medium (4 ГБ, $20). Локацию выбирайте по аудитории и железу: для российских и СНГ-пользователей Финляндия даёт минимальный пинг и самый быстрый процессор в линейке, Нидерланды — лучшую связность для европейского трафика, Польша удобна для Восточной Европы.
Start в Финляндии — $10/мес Start в Нидерландах — $10/мес
При заказе выбирайте Ubuntu LTS или Debian — под них больше всего инструкций. Через несколько минут после оплаты на почту придут IP-адрес и пароль root.
Шаг 2. Базовая настройка сервера (15 минут)
ssh root@IP apt update && apt upgrade -y adduser deploy && usermod -aG sudo deploy ufw allow OpenSSH && ufw allow 80 && ufw allow 443 && ufw enable
Затем отключите вход root по паролю: скопируйте свой SSH-ключ пользователю deploy (ssh-copy-id deploy@IP), в /etc/ssh/sshd_config поставьте PermitRootLogin no и PasswordAuthentication no, перезапустите ssh. Это закрывает 90% автоматических атак, которые начнутся в первые часы жизни сервера.
Шаг 3. Окружение
Классический стек для PHP-сайта на Ubuntu:
apt install -y nginx mariadb-server php8.3-fpm php8.3-mysql php8.3-gd \ php8.3-curl php8.3-mbstring php8.3-xml php8.3-zip certbot python3-certbot-nginx mysql_secure_installation
Версию PHP берите ту же, что была на хостинге, — её видно в phpinfo или в панели. Обновлять до новой версии лучше после переезда, отдельным шагом, чтобы не искать две проблемы одновременно.
Если ставите панель управления — этот шаг делает она; установите её до заливки сайта, а не после.
Шаг 4. Перенос файлов и базы
mkdir -p /var/www/site && cd /var/www/site # залейте архив по scp или rsync, распакуйте mysql -e "CREATE DATABASE site; CREATE USER 'site'@'localhost' IDENTIFIED BY 'пароль'; GRANT ALL ON site.* TO 'site'@'localhost';" zcat site.sql.gz | mysql site
Поправьте конфигурацию сайта (для WordPress — wp-config.php): имя базы, пользователь, пароль, хост localhost. Проверьте права: chown -R www-data:www-data /var/www/site.
Шаг 5. Проверка без переключения домена
Самый важный шаг, который и обеспечивает нулевой простой. Сайт уже работает на новом сервере, но домен пока ведёт на старый. Чтобы увидеть новый сервер только со своего компьютера, добавьте строку в файл hosts (/etc/hosts на Mac и Linux, C:\Windows\System32\drivers\etc\hosts на Windows):
NEW_IP example.com www.example.com
Теперь ваш браузер открывает example.com с нового сервера, а все остальные — со старого. Пройдите по сайту как пользователь и как администратор: главная, каталог, поиск, корзина и оплата (тестовым платежом), формы, загрузка файлов в админке, отправка почты, cron-задачи. Ошибки ищите в /var/log/nginx/error.log и логах PHP-FPM. Именно здесь всплывают забытые расширения PHP, права на папки и пути, прописанные абсолютно.
Сертификат SSL на этом этапе выпустить нельзя (домен ещё смотрит на старый сервер) — временно подготовьте конфигурацию Nginx на 80-й порт, сертификат добавите через минуту после переключения.
Шаг 6. Переключение
- Выберите время минимальной посещаемости — обычно ночь на понедельник.
- Переведите старый сайт в режим «только чтение» или заморозьте приём заказов на 10–15 минут — так вы не потеряете данные, созданные на старом сервере в момент переключения.
- Снимите свежий дамп базы со старого сервера и залейте на новый — с момента шага 4 там могли появиться новые заказы, комментарии, регистрации.
- Поменяйте A-записи домена на новый IP. С TTL 300 большинство пользователей перейдёт за 5 минут.
- Выпустите сертификат:
certbot --nginx -d example.com -d www.example.com. - Уберите строку из hosts и проверьте сайт ещё раз «как все».
Шаг 7. После переезда
- Не выключайте старый хостинг 3–7 дней. Часть пользователей и роботов ещё будет попадать туда по старым DNS-кэшам. Если на нём успели создать данные — заберите их.
- Перенесите почту. Если ящики были на хостинге, заведите их у почтового сервиса (или на VPS, но это отдельная задача) и поменяйте MX-записи.
- Настройте бэкапы сразу. Простейший вариант — ежедневный дамп базы и rsync файлов на второй дешёвый сервер в другой стране; подробнее на странице резервного копирования.
- Верните TTL DNS-записей к обычным значениям через неделю.
- Обновите PHP, если на хостинге была старая версия, — теперь это ваша зона и ваш выигрыш в скорости.
Типичные ошибки
- Переключать DNS до проверки через hosts. Тогда всё, что ломается, ломается у пользователей.
- Забыть про cron: на хостинге он был в панели, на VPS его нужно завести руками (
crontab -e). - Не снять свежий дамп перед переключением — терять заказы за последние сутки.
- Оставить root с паролем и firewall выключенным «на пару дней». Боты найдут сервер за час.
- Взять Lite для CMS с базой ради экономии $4 — и через неделю переезжать ещё раз.
Чек-лист
- TTL снижен за 2 дня.
- Копия файлов и базы снята и проверена.
- Список внешних настроек (cron, почта, редиректы, SSL) выписан.
- Сервер заказан, базовая безопасность настроена.
- Окружение развёрнуто, сайт залит, конфиг поправлен.
- Проверка через hosts пройдена полностью, включая оплату и формы.
- Свежий дамп → смена A-записей → сертификат.
- Старый хостинг живёт ещё неделю, бэкапы настроены на новом месте.