Перенос проекта с VPS на выделенный сервер
Переезд делают в четыре шага: поднимают зеркало окружения на новой машине, синхронизируют файлы через rsync и базу через дамп, проверяют проект по новому адресу без изменения DNS, затем переключают записи с коротким TTL. При такой схеме простой измеряется минутами финальной досинхронизации, а не часами.
- Снижайте TTL DNS-записей до 300 секунд за сутки до переключения, иначе часть посетителей будет ходить на старый сервер ещё день.
- Файлы переносите rsync за два прохода: длинный черновой на работающем проекте и короткий финальный после остановки записи.
- Базу переносите дампом с блокировкой на уровне транзакции, а не копированием каталога данных на живой СУБД.
- Старый VPS держите оплаченным ещё неделю — это самый дешёвый план отката.
Шаг 0. Инвентаризация и подготовка
Соберите список того, что реально работает на VPS: версии PHP, Python или Node, веб-сервер и его конфиги, СУБД и её версия, cron-задачи, systemd-юниты, сертификаты, ключи деплоя, внешние монтирования.
На новом сервере сразу сделайте базовую настройку: ключи SSH, обновления, файрвол, мониторинг. Порядок первых шагов на чистой машине описан в материале приёмка выделенного сервера, а общая логика переезда между типами хостинга — в статье выделенный сервер или VPS.
| Что переносим | Чем | На что смотреть |
|---|---|---|
| Файлы сайта и загрузки | rsync с ключами -aHAX | Права, владельцы, жёсткие ссылки, xattr |
| MySQL или MariaDB | mysqldump с single-transaction | Кодировка, процедуры, триггеры, события |
| PostgreSQL | pg_dump в формате custom | Расширения, роли, права на схемы |
| Пакеты и версии | dpkg или rpm со списком | Версия PHP и модули, версия СУБД |
| Регулярные задачи | crontab и systemd timers | Пользователь задачи, переменные окружения |
| Сертификаты | Копия каталога или новый выпуск | Цепочка, права на приватный ключ |
Шаг 1. Данные
# первый проход: можно выполнять на работающем проекте
rsync -aHAX --numeric-ids --delete \
-e 'ssh -p 22' /var/www/ root@NEW_IP:/var/www/
# дамп MySQL/MariaDB без блокировки таблиц InnoDB
mysqldump --single-transaction --quick --routines --triggers --events \
--databases shop > /root/shop.sql
# передаём и разворачиваем на новом сервере
scp /root/shop.sql root@NEW_IP:/root/
ssh root@NEW_IP 'mysql shop < /root/shop.sql'
# PostgreSQL: дамп и параллельное восстановление
pg_dump -Fc -U postgres shop > /root/shop.dump
pg_restore -U postgres -d shop -j 4 /root/shop.dump
# список пакетов со старой машины, чтобы повторить окружение
dpkg --get-selections | grep -v deinstall > pkgs.txt
Подробности по ключам дампа и по восстановлению отдельных таблиц разобраны в материале mysqldump: резервная копия и восстановление.
Шаг 2. Проверка до переключения DNS
Не переключайте домен «чтобы посмотреть, как получилось». Новый сервер проверяется по адресу, и только после этого трогают зону:
# запрос к новому серверу с правильным именем хоста и SNI
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' \
--resolve example.com:443:NEW_IP https://example.com/
# сравниваем ответ старого и нового узлов
diff <(curl -s --resolve example.com:443:OLD_IP https://example.com/) \
<(curl -s --resolve example.com:443:NEW_IP https://example.com/)
# проверяем, что сервисы подняты и слушают нужные порты
systemctl is-active nginx php8.3-fpm mariadb
ss -lntp | grep -E ':80|:443|:3306'
Копирование каталога данных СУБД на живом сервере обычной командой копирования даёт повреждённую базу: часть страниц попадёт в копию до записи, часть после, и таблицы InnoDB не пройдут проверку. Симптом проявляется не сразу — сайт открывается, а через сутки сыплются ошибки целостности на отдельных таблицах. Переносите базу дампом или останавливайте СУБД перед копированием файлов. Проверка после переезда: выполните проверку таблиц и сверьте количество строк в 5–10 ключевых таблицах со старой машиной; цифры должны совпасть до единицы. Отдельно проверьте почту: если проект отправляет письма сам, уточните политику исходящего SMTP — на VDS порты 25, 465 и 587 по умолчанию закрыты и открываются по запросу проверенным клиентам.
Шаг 3. Переключение
- За сутки снижаете TTL записей A и AAAA до 300 секунд.
- Включаете на старом сервере режим только для чтения или короткое техническое окно.
- Выполняете финальный rsync и свежий дамп базы — он занимает минуты, потому что основной объём уже перенесён.
- Меняете A-запись на адрес нового сервера, проверяете распространение и логи обоих узлов.
- Через сутки возвращаете TTL к обычному значению и снимаете с рассмотрения старый VPS.
Шаг 4. Что меняется после переезда
На выделенном сервере исчезают соседи по гипервизору, а вместе с ними — плавающая производительность диска. Появляются свои задачи: следить за состоянием RAID-массива и SMART, обновлять микрокод и ядро, планировать резервное копирование, потому что моментальных снимков гипервизора больше нет. Схему копий соберите сразу, по материалу резервное копирование выделенного сервера.
Подобрать конфигурацию под выросшую нагрузку можно в разделе выделенные серверы: типовой переезд с VPS идёт на Dedicated Start DE за $49 или на Pro DE с 32 GB ECC и NVMe за $99 в месяц.
Коротко
- Порядок: инвентаризация, зеркало окружения, данные, проверка по адресу, DNS.
- TTL снижают заранее, иначе переключение растягивается на сутки.
- База переносится дампом; копирование каталога данных на живой СУБД портит таблицы.
- Проверяйте новый узел через curl с подменой адреса до того, как трогать зону.
- После переезда заново настройте мониторинг железа и резервное копирование.