Переезд боевого сайта с одного VPS на другой обычно вызывает больше тревоги, чем нужно. Правильно спланированная миграция даёт даунтайм < 5 минут (или вообще 0 для read-mostly сайтов). Ниже — пошаговый план для типичной LEMP-стек (nginx + PHP-FPM + MySQL).
Подготовка (за 2-3 дня до)
Что делаем заранее.
- Снизить TTL DNS-записей до 300 сек (5 мин). Изменение подействует через 24-48 ч. Если не снизить — DNS-switch будет пропагироваться сутки.
- Заказать новый VPS, настроить точно тот же стек (nginx-версия, PHP-версия, MySQL-мажор).
- Скопировать конфиги
/etc/nginx/,/etc/php/,/etc/mysql/— синхронизировать с новым. - Тест на dev-домене:
newvps-ip site.example.comв /etc/hosts на локалке — проверить, что сайт открывается через IP нового VPS.
Первичная синхронизация (за 1-2 часа до)
Копируем данные rsync-ом. Это не финальная копия — пользователи ещё пишут в старый сервер, но 90 % файлов уже перевезены.
# на старом VPS
rsync -avz --delete /var/www/ [email protected]:/var/www/
rsync -avz --delete /etc/letsencrypt/ [email protected]:/etc/letsencrypt/
# dump БД
mysqldump --single-transaction --routines --triggers \
--databases mysite | gzip > /tmp/db-initial.sql.gz
scp /tmp/db-initial.sql.gz [email protected]:/tmp/
# на новом VPS
zcat /tmp/db-initial.sql.gz | mysqlФинальная синхронизация (downtime начинается)
Останавливаем запись на старом сервере, доделываем финальный rsync, дампим БД в актуальном состоянии.
# старый VPS: переключить в read-only
# для WP — плагин Maintenance Mode или nginx return 503
sudo ln -s /etc/nginx/sites-available/maintenance /etc/nginx/sites-enabled/
sudo nginx -s reload
# финальный rsync
rsync -avz --delete /var/www/ [email protected]:/var/www/
# финальный dump
mysqldump --single-transaction --routines --triggers \
--databases mysite | gzip > /tmp/db-final.sql.gz
scp /tmp/db-final.sql.gz [email protected]:/tmp/
# на новом
zcat /tmp/db-final.sql.gz | mysqlDNS-switch
Меняем A-запись домена на IP нового VPS. С низким TTL (300) — 5-15 минут пропагация.
Совет: не удаляйте старый VPS ещё 24-48 часов. Всегда есть шанс, что что-то не скопировалось или клиент попал на старый по кэшу DNS.
Верификация
После DNS-switch — контрольные проверки.
curl -Iv https://site.example.com/→ сертификат от Let's Encrypt действителен, отвечает 200.- Открыть 5-10 ключевых страниц (главная, категории, checkout).
- Проверить формы (submit, регистрация, оплата).
- Сверить количество записей в БД со старым сервером (
SELECT COUNT(*) FROM orders). - Проверить, что фоновые задачи (cron, воркеры) запустились на новом.
Восстановление TTL
После успешной миграции — вернуть TTL к нормальному значению (3600-86400). Иначе DNS-сервера будут постоянно спрашивать вашу зону.