Миграция сайта на новый сервер без простоя: rsync, база данных и переключение DNS

Переезд сайта на новый сервер — рутинная операция, но именно в момент миграции чаще всего теряются данные и появляется простой. Разберём, как перенести сайт без недоступности: подготовка, синхронизация данных, проверка на новом адресе и переключение DNS с минимальным TTL.

Что входит в переезд

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

# на старом сервере — снять «инвентарь»
ls /etc/nginx/sites-enabled/ 2>/dev/null
crontab -l > ~/crontab.txt 2>/dev/null
systemctl list-units --type=service --state=running | head -20
# версии стека
nginx -v 2>&1; php -v 2>/dev/null | head -1; psql --version 2>/dev/null; node -v 2>/dev/null

Зафиксируйте версии: перенос на значительно более новую версию PHP или PostgreSQL может сломать приложение даже при корректном копировании.

Подготовка: TTL и окно работ

Заранее уменьшите время жизни DNS-записи, чтобы переключение прошло быстро. Обычно за сутки-двое ставят TTL 60 секунд.

# проверить текущий TTL
dig +short example.com
dig example.com | grep -i "IN\s*A" -A3 | head
# уменьшить TTL у регистратора до 60 за 24-48 часов

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

Синхронизация файлов

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

# тестовый прогон (ничего не пишет)
rsync -avzn --delete /var/www/ new-server:/var/www/
# основной перенос
rsync -aHAX --info=progress2 --delete /var/www/ new-server:/var/www/
# повторить перед переключением — займёт секунды
rsync -aHAX --delete /var/www/ new-server:/var/www/

Каталог загрузок копируйте отдельно и начинайте первым: он самый объёмный и меняется чаще всего.

Перенос базы данных

Для больших баз используйте дамп с логическим экспортом и импортом в фоне, либо репликацию для синхронизации в реальном времени.

# выгрузка
pg_dump -Fc -Z6 -f /backup/site.dump site_db
# перенос
scp /backup/site.dump new-server:/tmp/
# импорт на новом сервере
createdb site_db
pg_restore -d site_db /tmp/site.dump
# сверка
psql -Atc "select count(*) from posts;"   # на обоих серверах

Сверяйте не только количество строк, но и максимальные идентификаторы: расхождение здесь означает, что данные устарели.

Проверка на новом сервере до переключения

Добавьте запись в /etc/hosts локальной машины или используйте curl с заголовком Host — так вы увидите новый сервер, не меняя DNS.

# с локального компьютера
curl -I -H 'Host: example.com' http://NEW_IP/
curl -k -I --resolve example.com:443:NEW_IP https://example.com/
# проверить ключевые страницы
curl -s --resolve example.com:80:NEW_IP http://example.com/ | head -20
# ошибки в логах нового сервера
sudo tail -30 /var/log/nginx/error.log

Пройдите по формам, входу, оплате и админке: именно там чаще всего ломаются пути и переменные окружения.

SSL-сертификаты

# скопировать сертификаты
rsync -a /etc/letsencrypt/ new-server:/etc/letsencrypt/
# или перевыпустить на новом сервере
sudo certbot --nginx -d example.com
# проверить срок
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Не забудьте о таймере обновления: на новом сервере certbot.timer должен быть активен.

Переключение DNS

1. Убедитесь, что последняя синхронизация выполнена.
2. Обновите A-записи на новые IP.
3. Следите за разрешением: dig на разных DNS-серверах.
4. Держите старый сервер включённым ещё 24–48 часов.
5. Наблюдайте логи обоих серверов.

# проверить, что запись обновилась
dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short
# отслеживать появляющиеся запросы на старом сервере
sudo tail -f /var/log/nginx/access.log

После переезда

• Верните TTL к прежнему значению.
• Проверьте почту, cron-задания и фоновые процессы.
• Обновите мониторинг: новые IP, алерты, резервное копирование.
• Проверьте бэкапы на новом сервере и их расписание.
• Следите за ошибками в журнале первые сутки.

# чек-лист
systemctl --failed
journalctl -b -p err | tail -30
crontab -l | head
sudo tail -20 /var/log/nginx/error.log

План отката

Перед переключением опишите, как вернуть всё назад: DNS-записи возвращаются на старый IP, база на старом сервере остаётся нетронутой до подтверждения. Именно наличие плана отката позволяет действовать спокойно.

# сохранить текущие записи
dig example.com +short > ~/dns-before.txt
dig example.com NS +short >> ~/dns-before.txt
# зафиксировать состояние старого сервера
systemctl list-units --type=service --state=running > ~/services-before.txt
df -h >> ~/services-before.txt

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

Если после переключения что-то сломалось

1. Быстро смотрите логи нового сервера: error.log и журнал приложения.
2. Если причина неясна и простой критичен — возвращайте DNS на старый IP.
3. Проверьте переменные окружения и права на файлы: самая частая причина 502 и 500.
4. Сверьте версии PHP/Node/PostgreSQL с планом переезда.
5. После исправления повторите сверку и только потом закрывайте старый сервер.

# диагностика на новом сервере
sudo tail -50 /var/log/nginx/error.log
journalctl -u php*-fpm -b --no-pager | tail -30
# права на файлы сайта
ls -ld /var/www/ /var/www/site
stat -c '%U:%G %a %n' /var/www/site

Фоновые задачи и почта

После переезда проверьте cron, очереди и почтовый шлюз: эти компоненты легко забыть, а они отвечают за письма и регулярные процессы.

# cron на новом сервере
crontab -l
ls /etc/cron.d/ 2>/dev/null
# очередь приложения
sudo systemctl status queue-worker --no-pager 2>/dev/null | head
# почта: тестовое письмо и SPF/DKIM
dig +short TXT example.com
dig +short MX example.com

Отправьте тестовое письмо через новый сервер и проверьте, не попадает ли оно в спам: после переезда часто меняется IP, и репутация адреса начинается с нуля.

Итог

Безопасный переезд строится на инвентаризации, заранее уменьшенном TTL, двойном прогона rsync, сверке базы и проверке сайта по IP до переключения. Старый сервер не выключайте сутки после миграции. План отката и проверенные бэкапы превращают рискованную операцию в формальность.