Миграция на другой VPS: переезд без потери данных

Миграция на другой VPS пугает ровно до того момента, пока вы не сделаете её по чек-листу. Перенос VPS — это не магия панелей управления, а четыре понятные операции: копирование файлов через rsync, дамп базы данных, проверка сайта по новому IP до смены DNS и переключение A-записи с заранее сниженным TTL. Если выполнять их в правильном порядке, простой сокращается до нескольких минут, а риск потери данных — практически до нуля. В этой инструкции разберём миграцию сервера на примере типового стека Nginx + PHP + MySQL на Ubuntu 24.04, но схема одинаково работает для Node.js, Python и любых других приложений.

Когда пора переезжать и что понадобится

Типичные причины переноса сервера: старый тариф упёрся в потолок по CPU или диску, хостер деградировал по качеству, нужен переезд в другую локацию или просто нашлись условия лучше. Например, на Cheap-Host тариф Pro за 750 ₽/мес даёт 12 vCPU, 16 ГБ RAM и 128 ГБ NVMe с KVM-виртуализацией — частый сценарий миграции как раз «переросли старый VPS, переезжаем на конфигурацию с запасом».

Для переезда понадобится:

• root-доступ (или sudo) к обоим серверам по SSH;
• доступ к DNS-панели домена — там будем менять TTL и A-запись;
• 2–3 часа времени и окно минимального трафика (обычно ночь);
• свежий бэкап старого сервера — на случай, если что-то пойдёт не так. Как его организовать, мы разбирали в статье о резервном копировании VPS по стратегии 3-2-1.

Общий план по времени выглядит так:

Шаг 1. Аудит старого сервера и снижение TTL DNS

Сначала зафиксируйте, что вообще переносим. Пробегитесь по серверу и выпишите версии и сервисы:

nginx -v
php -v
mysql --version
systemctl list-units --type=service --state=running
crontab -l
ls /etc/nginx/sites-enabled/

В список переноса обычно попадают: каталоги сайтов (/var/www), конфигурации Nginx/Apache, базы данных, SSL-сертификаты, cron-задачи, systemd-юниты самописных сервисов и переменные окружения приложений (файлы .env).

Сразу же — самое важное действие, которое все откладывают: зайдите в DNS-панель домена и снизьте TTL A-записи до 300 секунд (5 минут). По умолчанию TTL часто равен 3600–86400 секундам: это значит, что после смены IP провайдеры будут кешировать старый адрес до суток. С TTL 300 переключение по миру пройдёт за считаные минуты. Изменение TTL должно «расползтись» по кешам, поэтому делайте это за 24–48 часов до часа X. Подробнее о том, как устроены DNS-записи, — в статье про привязку домена к VPS.

Шаг 2. Разворачиваем новый VPS и базовое окружение

Закажите новый сервер заранее — платить лишний месяц за два сервера не придётся, достаточно пары дней пересечения. На Cheap-Host VPS выдаётся за 45–60 секунд: IP и SSH-доступ приходят сразу после оплаты, так что развернуть площадку можно в тот же вечер. Выбирайте ту же ОС или новее (например, с Ubuntu 22.04 на Ubuntu 24.04 — это нормальный момент для апгрейда) и ставьте то же окружение:

apt update && apt upgrade -y
apt install -y nginx php8.3-fpm php8.3-mysql mysql-server certbot python3-certbot-nginx rsync

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

Шаг 3. Перенос файлов через rsync

rsync — главный инструмент миграции: он копирует по SSH, сохраняет права и владельцев, докачивает только изменившиеся файлы. Это значит, что первый прогон можно сделать за день до переезда, а в час X повторить — и второй прогон займёт секунды, потому что перенесёт только дельту.

Запускайте со старого сервера (NEW_IP — адрес нового VPS):

# Файлы сайтов
rsync -avz --progress /var/www/ root@NEW_IP:/var/www/

# Конфигурации веб-сервера
rsync -avz /etc/nginx/sites-available/ root@NEW_IP:/etc/nginx/sites-available/

# SSL-сертификаты Let's Encrypt
rsync -avz /etc/letsencrypt/ root@NEW_IP:/etc/letsencrypt/

Ключи: -a — архивный режим (права, владельцы, симлинки, время), -v — подробный вывод, -z — сжатие при передаче. Если SSH на новом сервере слушает нестандартный порт, добавьте -e "ssh -p 2222". Для больших объёмов полезен флаг --partial — он сохраняет недокачанные файлы при обрыве соединения.

После копирования на новом сервере включите конфигурации сайтов и проверьте синтаксис:

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Шаг 4. Дамп и перенос базы данных

Базу нельзя переносить копированием каталога /var/lib/mysql на работающем сервере — получите неконсистентные данные. Правильный путь — логический дамп. Для MySQL/MariaDB:

# На старом сервере
mysqldump --single-transaction --routines --triggers \
  -u root -p mydb > /root/mydb.sql

# Передаём дамп на новый сервер
rsync -avz /root/mydb.sql root@NEW_IP:/root/

Флаг --single-transaction снимает консистентный снимок InnoDB-таблиц без блокировки сайта. На новом сервере создайте базу и пользователя с теми же реквизитами, что в конфиге приложения, и загрузите дамп:

mysql -u root -p -e "CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "CREATE USER 'myuser'@'localhost' IDENTIFIED BY 'strong_password';
GRANT ALL PRIVILEGES ON mydb.* TO 'myuser'@'localhost'; FLUSH PRIVILEGES;"
mysql -u root -p mydb < /root/mydb.sql

Для PostgreSQL логика та же: pg_dump -U postgres mydb > mydb.sql на старом сервере и psql -U postgres mydb < mydb.sql на новом. Этот тестовый дамп нужен для проверки — финальный, «боевой» дамп мы снимем ещё раз перед самым переключением.

Шаг 5. Проверка сайта по IP до смены DNS

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

На Linux/macOS отредактируйте /etc/hosts, на Windows — C:\Windows\System32\drivers\etc\hosts (от администратора), добавив строку:

NEW_IP example.com www.example.com

Теперь браузер на вашей машине откроет сайт с нового сервера — с работающим HTTPS, потому что сертификаты мы уже перенесли. Проверьте главную, вход в админку, формы, загрузку файлов, поиск.

Быстрая проверка без правки hosts — через curl:

curl --resolve example.com:443:NEW_IP https://example.com/ -I

Флаг --resolve подставляет нужный IP только для этого запроса. Ответ HTTP/2 200 и корректные заголовки — признак, что новый сервер готов. Нашли ошибки — чините спокойно: посетители их не видят. После проверки не забудьте убрать строку из hosts.

Шаг 6. Переключение DNS и финальная синхронизация

Час X. Порядок действий строгий, чтобы не потерять ни одного заказа или комментария:

1. Закройте запись на старом сервере. Включите режим обслуживания в CMS или отдавайте 503 из Nginx — чтобы за время переключения в старую базу не попали новые данные.
2. Финальный rsync. Повторите команды из шага 3 — уедет только дельта, это секунды.
3. Свежий дамп БД. Снимите дамп ещё раз, перенесите и загрузите в базу нового сервера (предварительно очистив тестовую: DROP DATABASE mydb; CREATE DATABASE mydb ...).
4. Смените A-запись домена на новый IP в DNS-панели. С TTL 300 трафик перетечёт за 5–15 минут.
5. Проверьте распространение: dig +short example.com должен вернуть новый IP. Следите за логами нового сервера: tail -f /var/log/nginx/access.log — запросы пойдут почти сразу.

Старый сервер не выключайте минимум 3–7 дней: остаточный трафик из DNS-кешей ещё будет капать, а заодно вскроются забытые cron-задачи и интеграции, привязанные к старому IP. Через сутки-двое верните TTL к обычным 3600 секундам. Если вместе с сервером переезжает и сайт с виртуального хостинга, пригодится смежная инструкция — как перенести сайт с хостинга на VPS без простоя.

Частые ошибки при миграции сервера

• TTL снижен в последний момент. Старый высокий TTL уже закеширован — переключение растянется на сутки.
• Единственный дамп БД снят до финального rsync. Всё, что пользователи создали между дампом и переключением, потеряно. Финальный дамп — только после закрытия записи.
• Забытые «мелочи»: cron-задачи, systemd-юниты, файлы .env, каталоги загрузок вне /var/www.
• Разные версии PHP/MySQL и молчаливо несовместимые конфиги. Именно поэтому проверка по hosts обязательна.
• Старый сервер удалён на следующий день. Держите его неделю — это дешёвая страховка.

FAQ

Сколько времени занимает миграция на другой VPS?

Подготовка и первый перенос данных — 1–3 часа для типового сайта. Сам простой при правильной схеме (предварительный rsync, низкий TTL, финальная досинхронизация) укладывается в 5–15 минут.

Можно ли перенести VPS вообще без простоя?

Полностью без простоя — только с репликацией БД и балансировщиком, что для типового проекта избыточно. Схема с финальной синхронизацией сокращает простой до минут, а посетители в переходный период продолжают видеть сайт со старого сервера.

Почему нельзя просто скопировать файлы базы данных вместо дампа?

Копирование файлов работающей СУБД даёт неконсистентную копию: часть данных находится в памяти и журналах транзакций. Логический дамп (mysqldump --single-transaction, pg_dump) гарантирует целостность и совместимость между версиями СУБД.

Когда возвращать TTL DNS обратно?

Через 24–48 часов после переезда, когда весь трафик идёт на новый сервер, а логи старого пусты. Верните TTL к 3600–86400 секундам.

Сколько держать старый сервер после миграции?

Минимум 3–7 дней. За это время всплывут забытые cron-задачи и интеграции, которые ещё стучатся на старый IP. Перед отключением снимите финальный бэкап старого сервера.

Вывод

Перенос VPS сводится к дисциплине: заранее сниженный TTL, rsync в два прохода, консистентный дамп базы, проверка по IP через hosts до смены DNS — и переключение с простоем в несколько минут. Один раз пройдя этот путь по чек-листу, вы перестанете быть заложником текущего хостера.

Если переезжаете в поисках сервера побыстрее и без переплат — у Cheap-Host тариф Pro от 750 ₽/мес: 12 vCPU, 16 ГБ RAM, 128 ГБ NVMe, KVM, безлимитный трафик и выдача сервера за минуту. Новый VPS можно развернуть и проверить по IP в тот же вечер, а если позже ресурсов станет мало — апгрейд CPU/RAM/диска выполняется без потери данных. Тарифы и заказ — на cheap-host.onl.