Переезд на VDS без потери данных: пошаговый план для бизнеса

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

Надёжный переезд начинается с ответа на два вопроса: какие данные меняются прямо сейчас и как мы вернём сервис к работе, если новый сервер не запустится? Ниже – практический порядок действий для сайта, CRM-интеграции или небольшого корпоративного сервиса. Он помогает снизить риск потерь, но не обещает абсолютного отсутствия простоя.

1. Составьте карту того, что действительно работает на сервере

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

• Приложение: код, версия языка и библиотек, веб-сервер, переменные окружения, конфигурационные файлы
• Данные: базы MySQL или PostgreSQL, загруженные документы и фотографии, отдельные каталоги хранения, постоянные тома контейнеров
• Интеграции: платёжные уведомления, формы заявок, CRM, телефония, исходящая почта, вебхуки и разрешённые IP-адреса
• Автоматические задачи: cron, очереди, обработчики, рассылки, планировщики и задания резервного копирования
• Доступы: SSH-ключи, пользователи и права на файлы, сертификаты TLS, DNS-записи и настройки межсетевого экрана

Рядом с каждым пунктом запишите, где он находится, кто отвечает за проверку и можно ли временно остановить запись. Например, сайт-визитка без личного кабинета переносится проще, чем интернет-магазин, который принимает заказы и оплаты круглосуточно.

2. Определите допустимое окно переключения

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

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

3. Создайте резервную копию и проверьте восстановление

Копию нужно хранить отдельно от сервера, который собираетесь переносить. Сохраните файлы приложения, пользовательские загрузки, конфигурацию и данные базы. Запишите дату и состав копии.

Проверьте восстановление на тестовой площадке. Успешное сообщение об экспорте ещё не доказывает, что сайт откроется с этой копии.

У разных данных разные правила копирования

Для обычных файлов подойдёт контролируемая синхронизация с проверкой списка переданных объектов. С базами осторожнее: копирование каталога работающей СУБД обычной файловой командой может дать непригодный набор файлов. У PostgreSQL для логического экспорта используют pg_dump, роли и другие общие объекты сервера проверяют отдельно. В MySQL применяют mysqldump, режим --single-transaction рассчитан прежде всего на транзакционные таблицы InnoDB и не решает автоматически вопрос согласованности всех типов таблиц.

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

4. Подготовьте новый VDS, не трогая старый

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

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

До смены DNS приложение можно проверить по временному техническому адресу или с локальным сопоставлением домена и нового IP, сохраняя правильное имя хоста и HTTPS. Но такой тест не заменяет проверку реальных внешних интеграций.

5. Сначала выполните пробный перенос

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

На пробе полезно обнаружить неожиданную зависимость от старого IP, локального дискового пути или почтового сервиса. После исправления повторите тест. Не стоит переносить заодно приложение на другую основную версию СУБД или переделывать архитектуру, если это не требуется: каждая дополнительная перемена затрудняет поиск причины сбоя.

6. Переключайте сервис по заранее согласованному плану

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

Только после проверки перенесённого состояния направляйте рабочий трафик на новый VDS.

Что происходит с доменом

При смене IP часто меняют записи DNS. Время их жизни (TTL) имеет смысл уменьшить заранее, чтобы прежние значения успели выйти из кешей. Но короткий TTL не означает мгновенного переключения всех пользователей: часть запросов некоторое время может попадать на прежний адрес. Для критичных сервисов заранее продумывают, куда попадут такие запросы и почему они не создадут записи во второй независимой базе.

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

7. После переезда проверьте не только главную страницу

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

• Домен открывает новый сервер по HTTPS, сертификат соответствует имени сайта
• Авторизация, личный кабинет, поиск и основные страницы работают
• Новые записи сохраняются и видны после повторного открытия страницы
• Файлы загружаются, скачиваются и соответствуют записям в базе
• Вебхуки, формы, CRM и отправка уведомлений проходят сквозную проверку
• Очереди и задания по расписанию выполняются без дублей
• Мониторинг, журналы ошибок и резервное копирование настроены уже для нового VDS

Для проверки платёжной цепочки используйте разрешённый тестовый сценарий провайдера, не создавая случайные реальные платежи. Записывайте результаты и время проверки. Если ошибка появилась после переключения, так будет проще определить момент и причину.

8. Подготовьте откат до начала работ

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

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

Старый сервер отключают лишь после согласованного периода наблюдения, проверки резервного копирования и подтверждения, что зависимостей от его IP или хранилища больше нет. Конкретная длительность этого периода зависит от работы сервиса, её нельзя назначить одинаковой для всех.

Короткий план, который можно передать исполнителю

• Составить перечень сервисов, данных, интеграций и ответственных
• Согласовать окно переключения и порядок остановки записей
• Сделать независимую копию и проверить восстановление
• Подготовить новый VDS и провести пробную миграцию
• Проверить файлы, базу, права, фоновые задачи и сертификаты
• Выполнить финальную синхронизацию и переключить трафик
• Принять работу по пользовательским сценариям и журналам
• Убедиться, что откат возможен без потери новых записей

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

Когда стоит привлечь администратора

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

В «Феерично Digital» можно обсудить настройку и перенос серверных сервисов, а перед миграцией отдельно продумать резервное копирование и восстановление. Это разные задачи: разовый переезд не следует путать с дальнейшим ежемесячным сопровождением. Стоимость работ рассчитывается после разбора конфигурации и состава данных.

Хороший результат переезда – когда у владельца бизнеса есть подтверждение сохранности данных, перечень пройденных проверок и понятный порядок действий на случай следующего сбоя. Сам новый IP-адрес ничего этого не гарантирует.