Как перенести сайт на другой VPS без потери данных

Перенос VPS — это смена работающего сервера, а не простое копирование каталога. Файлы, база данных, фоновые задачи, DNS, TLS-сертификаты и резервные копии должны перейти в согласованном порядке. Если переносить их независимо и сразу удалить старый сервер, часть посетителей может попасть на пустой сайт или записать данные уже не туда.

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

Составьте карту переноса

До команд запишите, что именно обслуживает сайт. Минимальный список включает домены и поддомены, каталоги приложения, базу данных, пользовательские загрузки, переменные окружения, службы systemd, задания cron или timers, версию среды выполнения, правила firewall и внешнюю почту. Отдельно отметьте данные, которые меняются после каждого действия посетителя.

Такой список помогает отличить исходный код от состояния. Код можно заново получить из Git, а загруженные изображения, записи базы и секреты существуют только в конкретном окружении, если для них не настроено отдельное хранилище.

Зафиксируйте исходное состояние старого VPS. Команды ниже показывают выпуск системы, активные службы, занятые порты и файловые системы; они ничего не изменяют:

cat /etc/os-release
systemctl --type=service --state=running --no-pager
sudo ss -lntup
df -hT

В результатах найдите веб-сервер, приложение, базу и все публичные порты. Сохраните вывод в рабочие заметки. Если на новом сервере предполагается другая версия ОС или базы, считайте это отдельным обновлением: сначала проверьте совместимость, затем планируйте перенос.

Подготовьте новый VPS независимо от старого

Создайте обычного администратора, настройте SSH-ключи, обновления и firewall. Установите требуемые пакеты, но не копируйте целиком /etc: там находятся машинные SSH-ключи, сетевые настройки и конфигурации, привязанные к старому серверу.

Каталоги приложения и данных создайте заранее с ожидаемыми владельцами. В примере код принадлежит пользователю deploy, а веб-сервер только читает опубликованный каталог:

sudo install -d -o deploy -g deploy -m 0750 /srv/app/releases
sudo install -d -o deploy -g deploy -m 0750 /srv/app/shared
sudo install -d -o deploy -g www-data -m 0750 /srv/app/current-public

install -d создаёт каталог и сразу задаёт владельца, группу и режим доступа. Имена пользователей и пути должны соответствовать вашей архитектуре. После выполнения проверьте их командой namei -l /srv/app/current-public: она покажет права каждого каталога в пути, а не только последнего.

Уменьшите DNS TTL заранее

TTL — срок, в течение которого DNS-резолвер может хранить старый ответ. Если текущий TTL велик, уменьшите его в панели DNS заранее и дождитесь окончания прежнего срока. Мгновенного переключения это не гарантирует, но сокращает период, когда разные посетители получают разные IP-адреса.

Запишите старый IP, новый IP и исходные значения DNS. Это будет планом возврата. Не удаляйте старую запись и не отключайте сервер на этом шаге.

Выполните предварительное копирование файлов

rsync сравнивает источник и назначение и при повторном запуске передаёт только изменения. Сначала используйте пробный режим. Завершающий слеш после /shared/ означает «содержимое каталога», а не сам каталог:

rsync -a --dry-run --itemize-changes \
  /srv/app/shared/ deploy@NEW_IP:/srv/app/shared/

Параметр -a включает рекурсивное копирование и сохраняет основные атрибуты, --dry-run запрещает запись, а --itemize-changes объясняет каждое планируемое изменение. Просмотрите список: неожиданный путь назначения или массовое удаление означает, что команду запускать в рабочем режиме нельзя.

Если список верен, повторите команду без --dry-run. Не добавляйте --delete на первом проходе: ошибочный путь с удалением способен очистить данные на новом сервере. Для ACL и расширенных атрибутов нужны отдельные параметры -A и -X, права на обеих сторонах и предварительная проверка, что они действительно используются.

Перенесите базу согласованным способом

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

Для PostgreSQL небольшой базы исходная команда может выглядеть так. Формат custom позволяет выбирать объекты при восстановлении и работает с pg_restore:

sudo -u postgres pg_dump --format=custom --file=/var/backups/app.dump appdb
sha256sum /var/backups/app.dump

Первая команда создаёт согласованный dump базы appdb, вторая печатает его SHA-256. Передайте файл на новый VPS по SSH, вычислите сумму ещё раз и сравните значения. Затем восстановите его в заранее созданную пустую базу и проверьте журнал pg_restore; точные роли и параметры доступа зависят от приложения.

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

Проверьте новый сервер до смены DNS

Открытие сайта по IP не проверяет выбор виртуального хоста и TLS для домена. curl --resolve временно связывает домен с новым IP только для одного запроса. В DNS при этом ничего не меняется:

curl --resolve example.com:443:NEW_IP \
  --fail --show-error --silent \
  --output /dev/null --write-out '%{http_code}\n' \
  https://example.com/

Ожидаемый результат — код 200 или другой заранее известный успешный ответ. Проверьте также страницу с данными, статический файл, форму без необратимой отправки и намеренно отсутствующий URL. Если TLS не проходит, изучите сертификат и имя домена, а не отключайте проверку параметром -k.

Убедитесь, что фоновые задачи на новом сервере пока выключены. Два одновременно работающих cron-задания способны отправить дублирующие письма или дважды обработать очередь.

Проведите короткое финальное переключение

Для сайта с изменяемыми данными включите режим обслуживания или остановите компонент, принимающий запись. После этого выполните второй rsync, создайте свежий dump базы и восстановите его на новом сервере. Повторите проверки через --resolve.

Только теперь измените DNS A/AAAA-записи. Если используется прокси или балансировщик, переключайте его origin по той же логике. Включите фоновые задачи на новом VPS и оставьте их выключенными на старом.

Проверяйте, какой адрес возвращают независимые резолверы, но оценивайте сайт по фактическим HTTP-запросам. DNS-ответ сам по себе не подтверждает работу приложения, базы или TLS.

Не допускайте расхождения данных во время возврата

После смены DNS часть клиентов может некоторое время обращаться к старому IP. Если оба сервера принимают запись в независимые базы, данные разойдутся. Самый простой вариант для небольшого проекта — оставить на старом VPS страницу обслуживания или проксировать запросы на новый сервер, когда это заранее проверено.

Если новый сервер работает неправильно и после переключения ещё не принимал значимых записей, верните прежние DNS-значения и восстановите обслуживание на старом VPS. Если новые данные уже появились, одного возврата DNS недостаточно: сначала определите источник истины и перенесите изменения, иначе часть записей будет потеряна.

Завершите перенос только после наблюдения

Проверьте доступность из разных сетей, журналы Nginx и приложения, отправку почты, фоновые задачи, срок сертификата, свободное место и создание новой резервной копии. У старого сервера не должно остаться активных задач, способных менять внешние данные.

Снимайте старый VPS с эксплуатации после окончания прежнего TTL и выбранного окна наблюдения. Перед удалением сохраните согласованную копию нужных данных и журнал переноса. Новый сервер сразу включите в обычный цикл наблюдения и ручного резервного копирования.

Если перенос вызван подозрением на взлом, не переносите бинарные файлы и конфигурации как доверенные. Для этого сценария нужен чистый сервер и восстановление доверенного состояния, а не обычная миграция.

Источники

• Rsync manual
• curl: name resolve tricks
• PostgreSQL: SQL dump
• RFC 1034: domain names, concepts and facilities