Как перенести сайт на VPS без потери данных
Безопасный перенос — это не одно копирование файлов, а управляемая смена окружения: инвентаризация, backup, тест на новом адресе, финальная синхронизация, DNS и план отката. Ниже — последовательность для сайта с базой данных и внешними интеграциями.
Выберите сценарий миграции
Для статического сайта достаточно скопировать файлы, проверить конфигурацию веб-сервера и переключить домен. Динамический проект сложнее: посетители продолжают создавать заказы, комментарии, учётные записи или сообщения, пока вы переносите базу. Если просто сделать дамп утром, а DNS сменить вечером, новые данные останутся на старом сервере.
| Сценарий | Простой | Подход |
|---|---|---|
| Статический сайт | Практически не нужен | Копия файлов, тест, DNS |
| Блог с редкими изменениями | Несколько минут | Финальный dump в коротком режиме обслуживания |
| Интернет-магазин | Нужно минимизировать | Предварительная копия + финальная синхронизация заказов и файлов |
| Высоконагруженный сервис | Может быть недопустим | Репликация, двойная запись или поэтапное переключение |
| Смена панели/стека | Зависит от совместимости | Отдельный тест и ручная проверка конфигурации |
Для обычного сайта лучше выбрать понятное короткое окно обслуживания, чем обещать нулевой простой и рисковать расхождением данных. Пользователям можно заранее показать время работ. Старый сервер не удаляйте сразу: он нужен для проверки и rollback.
Шаг 1. Составьте инвентаризацию
До заказа VPS зафиксируйте всё, от чего зависит проект. Кроме каталога сайта и основной базы часто существуют cron, очереди, Redis, загружаемые файлы, TLS-сертификаты, почтовые ящики, DNS-записи, переменные окружения, webhook, внешние API и доступы к object storage. Пропущенный пункт проявится уже после переключения.
- Домены, поддомены и полный набор DNS-записей.
- Размер файлов, базы, uploads и темп их роста.
- Версии Linux, веб-сервера, языка, расширений и СУБД.
- Системные пользователи, владельцы файлов и права каталогов.
- Cron, workers, очереди, systemd units или Compose-файлы.
- Почта сайта: SMTP, SPF, DKIM, DMARC и адреса форм.
- Секреты, API keys, webhook URLs и IP allowlists.
- Backup: где находится, как расшифровать и восстановить.
Снимите текущие метрики CPU, RAM, диска и трафика хотя бы за рабочую неделю. Они помогут выбрать новый тариф без гадания. Если статистики нет, начните с небольшого запаса и возможностью быстрого апгрейда; полезны общая методика выбора VPS и таблица CPU/RAM по задачам.
Шаг 2. Сделайте проверяемую резервную копию
Перед любыми изменениями создайте отдельную копию файлов и согласованный dump базы. Храните их не только на старом сервере: скачайте в независимое хранилище или локально. Запишите команды и версии инструментов, которыми будете восстанавливать.
Проверьте архив: откройте список файлов, убедитесь, что uploads не исключены ошибочным шаблоном, а dump содержит нужные таблицы. Лучший тест — развернуть копию во временном окружении. Backup, который никогда не восстанавливали, остаётся предположением.
Шаг 3. Подготовьте новый VPS
Установите поддерживаемую ОС, создайте отдельного пользователя с sudo и настройте вход по SSH-ключу. Отключать парольный вход следует после проверки, что ключ работает во второй сессии. Обновите пакеты, включите firewall и откройте только необходимые порты.
Разверните веб-сервер, runtime и базу совместимых версий. При большом скачке версии сначала проверьте документацию приложения и миграции. Например, старый PHP-проект может использовать удалённые функции, а новая СУБД — более строгие настройки. Лучше сначала повторить близкое окружение, перенести сайт и только потом обновлять компоненты по одному.
Настройте время и часовой пояс осознанно: приложение, база и логи желательно хранить в согласованной временной зоне. Создайте каталоги, пользователей БД и конфигурацию, но не открывайте базу всему интернету. Для WordPress есть отдельное руководство по подготовке VPS под CMS, для контейнеров — материал про Docker на VPS.
Шаг 4. Перенесите файлы и базу
Первую копию можно сделать заранее, пока старый сайт работает. Инструмент файловой синхронизации должен сохранять структуру и при необходимости владельцев, но после переноса всё равно проверьте права. Не делайте весь каталог доступным на запись веб-процессу: приложению обычно нужны только отдельные uploads, cache или runtime-директории.
Импортируйте базу в отдельного пользователя с минимальными правами. Проверьте кодировку, collation, timezone и sql mode. Если домен или абсолютный путь меняется, не выполняйте слепую текстовую замену по бинарному dump: сериализованные данные некоторых CMS требуют специального инструмента.
Секреты переносите защищённым каналом и после миграции при возможности ротируйте. Не кладите production env-файл в публичный репозиторий. Если доступ к внешнему сервису ограничен IP, добавьте новый адрес заранее, не удаляя старый до окончания проверки.
Шаг 5. Проверьте сайт до смены DNS
Самый надёжный способ — временно направить домен на новый IP только на своём компьютере через hosts. Тогда браузер отправит правильный Host header, HTTPS и маршруты будут ближе к рабочим. Альтернативный тестовый поддомен тоже подходит, но приложение может вести себя иначе из-за cookies, CORS и абсолютных URL.
- Откройте главную, типовые внутренние страницы и страницу 404.
- Проверьте вход, регистрацию, поиск, загрузку файлов и формы.
- Создайте тестовый заказ или другую ключевую транзакцию.
- Убедитесь, что cron и workers запускаются ровно в одном месте.
- Проверьте отправку почты и заголовки сообщения.
- Посмотрите access/error logs и ошибки приложения.
- Сравните время ответа и потребление ресурсов со старым сервером.
- Проверьте backup и восстановление уже на новом VPS.
Не ограничивайтесь тем, что «главная открывается». Ошибки часто скрываются в админке, webhooks, генерации документов, фоновых заданиях и редких типах файлов. Составьте короткий smoke-чек именно для бизнеса проекта.
Шаг 6. Выполните финальную синхронизацию и смените DNS
За день или больше уменьшите TTL основной записи, если текущий DNS-провайдер это позволяет. Низкий TTL не гарантирует мгновенное обновление у всех резолверов, но обычно сокращает период смешанного трафика. Не меняйте nameservers и адрес сервера одновременно без необходимости: это усложняет диагностику.
В согласованное окно включите режим обслуживания или запретите операции записи, сделайте финальный dump базы и синхронизацию изменившихся файлов. Остановите cron и workers на старом сервере, запустите их на новом, затем измените A/AAAA-записи. Если используется CDN или proxy, обновите origin в его панели.
Некоторое время запросы будут приходить на оба адреса. Старый сайт должен либо оставаться в read-only, либо перенаправлять на новый, если схема это допускает. Следите за логами обоих серверов и не вносите независимые изменения в две базы.
Шаг 7. Проверки после переключения
- DNS из нескольких сетей возвращает новый IPv4/IPv6.
- TLS-сертификат покрывает домен и поддомены, цепочка корректна.
- Нет циклов HTTP/HTTPS или www/non-www redirect.
- Формы, заказы, webhooks, SMTP, cron и workers работают.
- Новые файлы появляются в правильном storage и попадают в backup.
- Поисковые роботы получают прежние URL, canonical, robots и sitemap.
- Мониторинг проверяет новый адрес, а оповещения доходят ответственному.
- CPU, RAM, disk latency, ошибки 5xx и место остаются в нормальном диапазоне.
Верните разумный TTL после стабилизации. Старый сервер держите доступным несколько дней или срок, соответствующий риску проекта, но закройте на нём запись и автоматические задания. Только после подтверждения данных и backup удаляйте услугу.
План отката
Rollback должен быть написан до миграции. Для простого сайта это возврат DNS на старый IP и запуск старых workers. Для магазина всё сложнее: если на новом сервере уже появились заказы, откат без обратной синхронизации потеряет их. Поэтому заранее определите точку, после которой возвращаться нельзя, а проблему нужно исправлять на новом окружении.
Храните контрольные суммы важных файлов, время последнего dump и журнал действий. Во время аварии короткая инструкция полезнее памяти администратора.
Частые ошибки
- DNS меняют до теста. Совместимость обнаруживают реальные посетители.
- Копируют только файлы. Теряются база, cron, секреты или загруженные пользователями данные.
- Обновляют всё одновременно. Невозможно понять, что вызвало ошибку.
- Два worker выполняют одну очередь. Задачи и письма дублируются.
- Не переносят почтовые настройки. Формы принимают сообщение, но оно не приходит.
- Старый VPS удаляют сразу. Исчезает быстрый rollback и возможность сверить данные.
- IPv6 указывает на старый сервер. Часть пользователей видит другую версию сайта.
- Забывают robots/canonical/sitemap. Технически работающий сайт получает SEO-проблемы.
Частые вопросы
Сколько длится перенос сайта?
Небольшой подготовленный сайт можно перенести за несколько часов. Большой объём данных, смена версий и критичные транзакции требуют отдельного тестового цикла. Основное время занимает не копирование, а проверка.
Можно ли перенести сайт без доступа к панели старого хостинга?
Нужен хотя бы доступ к файлам, базе и DNS. Если чего-то нет, сначала восстановите доступ или попросите провайдера создать экспорт. Переезд без полной копии рискован.
Нужно ли переносить SSL-сертификат?
Часто проще выпустить новый сертификат на новом сервере. Для проверки до DNS может потребоваться DNS challenge или временная схема. Закрытый ключ передавайте только защищённо.
Когда отключать старый сервер?
После завершения DNS-перехода, проверки бизнес-функций, сверки новых данных и успешного внешнего backup. Для важного проекта разумно оставить запас в несколько дней.
Как выбрать новый VPS?
Смотрите на фактическую текущую нагрузку, объём данных, локацию, возможность апгрейда и полную стоимость. Начните с каталога VPS по параметрам, отфильтровав минимальные ресурсы.
Если переносите CMS, дополнительно проверьте чек-лист VPS для WordPress.