Миграция сайта на VPS в Беларуси: план без простоев

Миграция сайта на VPS в Беларуси почти всегда сводится к одной задаче: подготовить новую среду заранее и переключить трафик так, чтобы пользователи это почти не заметили. Полностью “нулевое” время простоя в реальности гарантировать сложно из‑за DNS и синхронизации данных, но сделать релиз с минимальными окнами легко, если действовать как при blue-green развертывании.

Ниже пошаговый план без простоев: параллельно поднимаем целевую VPS-среду, переносим код и данные, обеспечиваем непрерывную синхронизацию базы, затем аккуратно переключаем трафик и фиксируем “точку истины”. На каждом этапе есть проверки, чтобы не упереться в проблему в момент cutover.

—

Подготовка: аудит сайта, инфраструктуры и рисков

Начните с того, что у вас реально “уезжает” на VPS, а не с общих слов про перенос. Составьте список компонентов сайта: веб-сервер, приложение (PHP/Node/Python/Java), очередь/кэши, база данных, фоновые задачи, загрузка файлов, внешние сервисы (почта, SMS, платежи), планировщик, cron, интеграции.

Дальше оцените источники данных и частоту изменений:

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

Отдельно проверьте, что вы знаете, где сейчас лежат секреты и конфиги. Обычно это:

переменные окружения и файлы с ключами;
доступы к БД, SMTP, API;
настройки webhooks и обратных URL;
правила для CORS, доверенных доменов, cookie domain/path.

Типичная ошибка перед миграцией — “перенести сайт”, но забыть про cron, кеш на файловой системе, очереди и внешние обработчики. Из-за этого после cutover часть функционала кажется сломанной, хотя веб работает.

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

до переключения: новая среда получает код и непрерывно синхронизируется;
на переключении: вы меняете способ обслуживания запросов;
после переключения: вы держите возможность отката и проверяете бизнес-метрики.

—

Поднимаем целевую VPS-среду в Беларуси и готовим окружение

Следующий шаг — подготовить сервер так, чтобы он был максимально похож на рабочую среду. Это уменьшает разрыв “у нас на проде работает, а на VPS — нет” и ускоряет запуск.

Выберите параметры VPS
ОС и версия должны быть совместимы с вашим стеком (например, PHP 8.x, Node 20.x, Python 3.x).
Память и диски подбирайте по пиковым нагрузкам на БД и кэши.
Проверьте скорость диска и тип хранилища (для БД это критично).
Настройте базовую сетевую безопасность: firewall, правила входящего трафика, ограничение SSH по ключам.

Разверните базовые компоненты

Обычно это:

Nginx или Apache (в зависимости от текущей системы);
PHP-FPM/HHVM/приложение или системный сервис (systemd);
TLS-сертификаты (и автоматическое продление, если используете);
логирование и ротация логов (logrotate или аналог);
системные переменные окружения для приложения.

Подготовьте структуру под релизы

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

отдельные директории для релизов (например, /var/www/app/releases/…);
symlink на текущую версию (например, /var/www/app/current);
или контейнерный подход, если он уже ваш стандарт.

Параллельная среда нужна именно для того, чтобы вы могли переключиться между “старым” и “новым” без остановки процесса разработки/инициализации.

—

Перенос кода и данных: как избежать рассинхронизации

Чтобы не ловить рассинхронизацию, разделите миграцию на две параллельные линии: код и данные.

Перенос кода
Подготовьте репозиторий и способ деплоя на VPS (git pull + сборка, или готовые артефакты).
Убедитесь, что конфиги приложений вынесены отдельно (env-файлы, конфиги для Nginx).
Проверьте сборку и линтеры, если они есть в вашем пайплайне.

Практика для снижения рисков: делайте одинаковые версии зависимостей и сборки. Если в проде используется composer/npm с lock-файлами — используйте их и на VPS.

Настройка статических файлов и загрузок

Определите, где лежат файлы:

в локальной файловой системе сервера (например, /uploads);
в отдельном хранилище (S3/MinIO);
в базе (редко, но бывает).

Если сейчас файлы лежат на диске сервера, вам нужно либо перенести их на VPS заранее, либо настроить внешнее хранилище. Для “без простоев” лучше, когда файлы вынесены в объектное хранилище, но если этого нет, хотя бы сделайте синхронизацию и следите за тем, что при cutover пользователи могут загружать новые файлы.

Первичная загрузка данных

Для начала перенесите состояние базы и файлов:

дамп БД (или бэкап) на VPS;
копирование файлов на VPS (если они локальные);
перенос настроек окружения, которые влияют на пути, URL и доступы.

После первичной загрузки обязательно проверьте, что приложение может работать “на новой среде” в режиме read-only или ограниченного теста. Иначе вы узнаете о проблеме прямо в момент переключения.

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

—

Настройка базы данных и миграций без остановки

Большинство “простоев” при миграции случается не из‑за веб-сервера, а из‑за БД: нужно гарантировать, что данные на VPS достаточно актуальны к моменту переключения.

Есть два подхода, которые реально работают в большинстве сценариев.

Подход A: репликация/непрерывная синхронизация до cutover

Если у вас MySQL/MariaDB или PostgreSQL, можно сделать так, чтобы VPS не просто получил дамп, а начал получать изменения до релиза.

Общий принцип:

поднимаете целевую БД на VPS;
настраиваете репликацию или CDC-подобную схему (в зависимости от стека);
периодически проверяете отставание (lag);
миграцию данных завершаете “финальным синком” перед переключением.

Что важно проверить заранее:

права на репликацию (GRANT/roles);
сетевой доступ между текущей БД и новой БД;
совпадение версий и настроек параметров, которые влияют на формат данных;
блокировки при DDL (если у вас миграции меняют схему, проверьте, как они будут выполняться).

Минус подхода A: настройка может занять время и потребовать внимательной настройки прав и параметров. Плюс в том, что вы реально минимизируете риск потери “новых” данных.

Подход B: короткое окно “final sync” без долгого простоя

Когда репликация сложна или ограничена, используют схему с коротким окном:

делаете первичную копию БД на VPS;
запускаете предрелизную синхронизацию данных;
перед переключением переводите критичные операции в контролируемый режим (например, временно ограничиваете запись через приложение или включаете read-only для части эндпоинтов);
выполняете быстрый финальный экспорт/импорт изменений;
переключаете трафик.

Этот вариант ближе к “почти без простоев”, но требует дисциплины в приложении: вы должны понимать, какие операции критичны (создание заказов, регистрация, платежные статусы, загрузки).

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

backward-compatible миграции (добавить новые поля, не удаляя старые, обновить код, потом убрать старое);
поэтапные релизы (сначала код, потом схема или наоборот, в зависимости от текущей архитектуры).

—

Переключение трафика: DNS, прокси и контроль времени

Это самый чувствительный этап. Если вы всё подготовили, задача будет выглядеть просто: “перевести запросы на новую среду” и проверить, что всё работает.

Выбор точки переключения

Есть несколько вариантов:

DNS переключение A/AAAA на IP VPS.
Прокси/балансировщик перед сайтами (если он у вас есть): переключение backend.
Использование CDN/edge-прокси, если он стоит перед доменом: управление origin или маршрутизацией.

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

Практика DNS cutover без паники

Подготовьте TTL заранее

Если вы можете менять TTL в DNS-зоне, снизьте его за несколько часов или день до релиза (по возможностям вашего регистратора/провайдера DNS). Это уменьшит “долгое расхождение” для пользователей.

Проверьте резолвинг заранее

Перед переключением убедитесь, что новый IP доступен из нужных сетей. Часто проблема не в настройке, а в том, что firewall/маршрутизация блокируют трафик.

Если есть возможность — делайте постепенность

Некоторые провайдеры дают weighted DNS или несколько записей. Если это доступно, используйте постепенность, а не “всё сразу”. Если нет — готовьтесь к короткому окну повторных запросов: браузер и приложения должны пережить возможные задержки на отдельных резолверах.

Контроль во время переключения

Сделайте cutover как последовательность:

убедиться, что новая среда отвечает по healthcheck;
включить редиректы/обслуживание запросов по целевому домену;
проверить критичные маршруты: главная, логин/регистрация, оформление заказа, загрузка файлов (если есть), API endpoints;
следить за ошибками в логах и метриках.

Если у вас есть webhooks или внешний сервис обращается к вашему домену, важно, чтобы URL не поменялся. Иначе получится ситуация, когда сайт “откликается”, но интеграции не доходят.

—

Проверка после релиза и процедуры отката

Даже если “всё выглядит хорошо”, проверка должна быть системной. Разделите проверки на несколько уровней и выполняйте их в первые 10–30 минут после переключения.

Технические проверки
код ошибки: 200/3xx на ключевых страницах и отсутствие всплеска 4xx/5xx;
время ответа: нет ли резкого деграда;
TLS: сертификат валиден, нет перенаправлений в неправильную сторону;
статика: картинки, скрипты, стили грузятся без 404.

Проверки данных и сессий
работает ли авторизация и сессии;
корректно ли выставлены cookie domain/path (это частая проблема при смене прокси или схемы);
нет ли расхождения между окружениями (например, разные параметры базы или неверные лимиты).

Бизнес-проверки
создание тестового объекта (заявка/заказ) проходит до конца;
отправка уведомлений (почта/уведомления) не ломается;
загрузка файлов и последующая выдача по URL работают.

Откат: заранее подготовьте, как вы вернётесь

Откат должен быть быстрым, иначе он превращается в ещё один релиз. Для отката подготовьте:

заранее сохранённую конфигурацию старой среды;
DNS rollback план: куда возвращать записи;
контрольный список, что делать, если ошибки растут (например, вернуть обслуживание на старый backend, оставить новую БД в ожидании, остановить фоновые задачи).

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

—

Типичные ошибки при миграции на VPS и как их предупредить

Ниже ошибки, которые чаще всего приводят к простоям или “тихим” инцидентам после переключения.

Не совпали версии компонентов

Симптомы: PHP-ошибки, несовместимость зависимостей, сбои сборки. Решение: используйте те же версии, что в текущем проде, и проверяйте lock-файлы.

Забыли про cron и фоновые задачи

Симптомы: не отправляются письма, не обновляются статусы, “зависают” витрины. Решение: перенесите cron/очереди в новую среду и проверьте их выполнение до cutover.

Несовместимость конфигураций Nginx/Proxy

Симптомы: неправильно работают редиректы, ломается загрузка больших файлов, неверно определяется IP пользователя. Решение: перенесите конфиг и учтите X-Forwarded-For, clientmaxbody_size и правильные proxy headers.

Проблемы с cookie и доменом

Симптомы: “разлогинивает”, сессии не сохраняются, CSRF ошибки. Решение: проверьте cookie domain, схему (http/https), настройки CORS и доверенные origin.

Файлы лежат локально, а синхронизация не закрывает “окно”

Симптомы: пользователи загружают файл, а после переключения он “не находится”. Решение: либо переносите файлы в объектное хранилище, либо делайте финальную синхронизацию и учитывайте, что во время cutover загрузки могут потребовать отдельного режима.

Сделали миграцию без плана совместимости схемы

Симптомы: приложение падает из‑за отсутствующих колонок или неожиданных данных. Решение: делайте миграции, которые не ломают текущий код, и обновляйте компоненты поэтапно.

—

Чек-лист перед стартом и бысткий план действий

Чтобы миграция сайта на VPS в Беларуси прошла без простоев, держите короткий чек-лист. Его можно использовать как основу для таск-трекера.

Перед развертыванием
[ ] Есть список компонентов сайта (код, БД, кеши, очередь, фоновые задачи, файлы).
[ ] Зафиксированы версии и конфиги текущего прод-окружения.
[ ] Подготовлен план cutover: куда переключаем и что проверяем сразу после.

На целевой VPS
[ ] Подняты веб-сервер, runtime и базовые сервисы.
[ ] Приложение собирается/запускается в новой среде.
[ ] Настроены логирование, ротация логов и healthcheck endpoint.

Данные
[ ] Выполнен перенос БД (дамп/репликация) и понятна стратегия финального синка.
[ ] Файлы перенесены или вынесены во внешнее хранилище.
[ ] Миграции схемы согласованы с совместимостью кода.

Под переключение
[ ] TTL снижен заранее (если делаете DNS cutover).
[ ] Проверен доступ к новому IP из нужных сетей.
[ ] Подготовлен откат: обратное переключение и инструкции для команды.

После переключения
[ ] Проверены ключевые маршруты, авторизация, загрузки и критичные бизнес-операции.
[ ] Наблюдение ведётся за ошибками и временем ответа.
[ ] Подготовлено решение на случай роста 4xx/5xx (возврат на старый backend).

Если вам нужно уложиться в минимальный простой, ориентируйтесь на такую последовательность по календарю:

за несколько дней: поднять VPS, развернуть окружение, перенести код и настроить окружения;
за несколько дней: подготовить перенос БД и файлов, протестировать параллельную работу;
накануне: прогнать тестовый cutover в “условном режиме” и проверить все healthcheck/логины/загрузки;
в день релиза: выполнить финальный sync данных, переключить трафик и провести проверки по чек-листу.

Начните с аудита и подготовки целевой среды. Дальше — данные и репликация/финальный синк, и только потом DNS или прокси. Такой порядок и создаёт “без простоя”: вы не начинаете миграцию в момент, когда пользователи уже ждут ответы, а завершаете её в момент, когда всё готово к работе на новой VPS.

Если хотите, можете прислать стек (например, Nginx + PHP, Node, WordPress, Laravel и т.д.), тип БД и где сейчас хранятся файлы. Под это я соберу более узкий план миграции с конкретными шагами под ваш сценарий.