База знаний

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

Главная цель — не просто “перенести сайт”, а не потерять заявки, заказы, формы, письма, файлы пользователей, SEO-трафик и доступность проекта. Особенно внимательно нужно переносить сайты на WordPress, WooCommerce, Laravel, Bitrix, OpenCart, CRM, SaaS-проекты, личные кабинеты и любые сайты, где пользователи что-то отправляют или оплачивают.

Что значит перенос без простоя

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

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

Главные риски при переносе сайта на VPS

• DNS обновляется дольше, чем ожидалось.
• На новом VPS не хватает нужных PHP-модулей или расширений.
• Версия PHP, MySQL или MariaDB отличается от старого сервера.
• Файлы перенесены, но база данных импортирована с ошибками.
• Забыты cron-задачи, queue workers, background jobs или webhooks.
• SSL-сертификат не установлен до переключения.
• Сайт открывается по IP, но не работает по домену.
• Почта, SMTP, SPF, DKIM или DMARC не перенесены.
• Формы отправляют заявки на старый адрес или не отправляют вообще.
• После переключения часть пользователей попадает на старый сервер, часть — на новый.
• Во время миграции новые заказы или заявки остаются в старой базе.
• Нет плана отката, если новый VPS работает неправильно.

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

Шаг 1. Определите тип сайта

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

• Статический сайт переносится проще всего: HTML, CSS, JS, изображения и конфиги веб-сервера.
• WordPress или другой CMS-сайт требует переноса файлов, базы данных, uploads, плагинов, темы и конфигурации.
• Интернет-магазин требует особой аккуратности, потому что во время миграции могут появляться новые заказы.
• Laravel, Node.js, Python или Go-приложение требует переноса кода, env-файлов, базы данных, storage, cron, queue workers и systemd-сервисов.
• CRM или личный кабинет требует контроля сессий, файлов пользователей, API-интеграций, почты и webhooks.

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

Шаг 2. Зафиксируйте текущую инфраструктуру

Перед началом переноса нужно описать, как сайт работает сейчас. Без этого легко перенести только видимую часть сайта и забыть важные сервисы.

Проверьте и сохраните:

• домен и текущие DNS-записи;
• текущий IP старого сервера;
• панель управления, если она используется;
• операционную систему;
• версию PHP, Node.js, Python или другого runtime;
• версию MySQL, MariaDB или PostgreSQL;
• список сайтов и доменов на сервере;
• пути к файлам сайта;
• конфиги веб-сервера;
• SSL-сертификаты;
• cron-задачи;
• очереди и фоновые процессы;
• SMTP-настройки;
• webhooks и внешние интеграции;
• объем файлов и базы данных;
• где хранятся backup-копии.

Если текущий сервер старый и плохо документирован, перенос нужно начинать именно с инвентаризации. Иначе новый VPS может быть настроен правильно, но сайт все равно не заработает из-за забытой зависимости.

Шаг 3. Выберите VPS с запасом

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

Для небольшого сайта компании обычно достаточно 2 vCPU и 2–4 GB RAM. Для WordPress с Elementor лучше смотреть на 2 vCPU и 4 GB RAM. Для WooCommerce, CRM, личного кабинета или активного сайта лучше выбирать 4 vCPU и 8 GB RAM или выше. Если проект уже дает продажи или заявки, слабый тариф создаст риск сразу после переезда.

Также важны:

• NVMe-диск для базы данных и файлов;
• 1 Gb/s порт для быстрой синхронизации и нормальной работы сайта;
• выделенный IPv4;
• DDoS-защита для публичного проекта;
• поддержка 24/7;
• возможность быстро увеличить ресурсы;
• понятная панель или root-доступ;
• локация, близкая к аудитории сайта.

Шаг 4. Подготовьте новый VPS до переноса

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

На новом VPS нужно заранее подготовить:

• операционную систему;
• обновления безопасности;
• firewall;
• SSH-доступ;
• веб-сервер Nginx или Apache;
• нужную версию PHP и расширения;
• MySQL, MariaDB или PostgreSQL;
• Redis, если он используется;
• Node.js, Python или другой runtime, если нужен;
• SSL-сертификат или готовность его выпустить;
• пользователей и права доступа;
• директории для сайта;
• backup-схему;
• мониторинг базовых ресурсов.

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

Шаг 5. Снизьте DNS TTL заранее

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

Практический порядок:

• за 24–48 часов до миграции снизьте TTL для A-записей домена;
• для основного домена и www установите короткий TTL, например 300 секунд;
• проверьте, где управляется DNS: у регистратора, Cloudflare, панели хостинга или другого DNS-провайдера;
• не меняйте nameserver без необходимости прямо во время миграции;
• зафиксируйте текущие DNS-записи до изменений.

Снижение TTL не переносит сайт само по себе. Оно только помогает быстрее переключить пользователей на новый VPS, когда все уже готово.

Шаг 6. Сделайте полный backup

Перед переносом нужен полный backup, а не “копия на всякий случай”. Backup должен позволять восстановить сайт на старом или новом сервере.

В backup должны входить:

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

Backup нужно проверить. Архив, который не распаковывается, или дамп базы, который не импортируется, не является рабочей страховкой.

Шаг 7. Перенесите файлы на новый VPS

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

Что важно проверить после переноса файлов:

• структура директорий совпадает с ожидаемой;
• права на файлы и папки выставлены корректно;
• владелец файлов соответствует пользователю веб-сервера;
• uploads, storage, cache и tmp доступны для записи;
• не перенесены лишние старые backup-архивы в публичную директорию;
• закрыты конфиденциальные файлы, например .env, config.php, backup.sql;
• статические файлы открываются на новом сервере.

Для WordPress особенно важно перенести wp-content, uploads, plugins, themes и wp-config.php. Для Laravel — storage, public, .env, composer dependencies, queue и cron. Для Node.js — package-файлы, env, process manager или systemd-сервис.

Шаг 8. Перенесите базу данных

Для динамического сайта база данных — самая важная часть переноса. В ней находятся записи, пользователи, заказы, формы, настройки CMS, товары, сессии и данные плагинов.

Перед импортом базы на новый VPS проверьте:

• версию MySQL, MariaDB или PostgreSQL;
• кодировку и collation;
• размер базы;
• наличие больших таблиц;
• ограничения на max_allowed_packet;
• права пользователя базы данных;
• доступ приложения к новой базе;
• ошибки при импорте.

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

Шаг 9. Настройте конфиги и переменные окружения

После переноса файлов и базы нужно проверить конфигурацию приложения. Частая ошибка — перенести файлы, но оставить старые пути, старый hostname базы или старые абсолютные URL.

Проверьте:

• адрес базы данных;
• имя базы;
• пользователя и пароль базы;
• пути к директориям;
• APP_URL или site_url;
• SMTP-сервер;
• ключи API;
• webhook URL;
• права на storage/cache;
• настройки Redis или Memcached;
• режим debug;
• секретные ключи и токены.

Для WordPress проверьте wp-config.php, DB_HOST, DB_NAME, DB_USER, DB_PASSWORD, WP_HOME и WP_SITEURL, если они заданы. Для Laravel проверьте .env, APP_KEY, APP_URL, DB_*, CACHE_*, QUEUE_* и настройки почты.

Шаг 10. Протестируйте сайт до смены DNS

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

Минимальный тест:

• главная страница открывается;
• внутренние страницы открываются;
• админка работает;
• авторизация работает;
• формы отправляются;
• письма уходят;
• изображения отображаются;
• CSS и JS загружаются;
• поиск работает;
• корзина и checkout работают, если есть магазин;
• личный кабинет работает, если он есть;
• API и webhooks отвечают;
• cron-задачи выполняются;
• логи не показывают критических ошибок.

Тестировать новый VPS можно через временный домен, hosts-файл на компьютере или отдельный staging-домен. Это позволяет открыть сайт на новом сервере до того, как его увидят пользователи.

Шаг 11. Выпустите или подготовьте SSL

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

Проверьте:

• есть ли SSL для основного домена;
• есть ли SSL для www;
• есть ли SSL для поддоменов;
• корректно ли настроен редирект HTTP на HTTPS;
• нет ли mixed content;
• работает ли автопродление сертификата;
• не привязан ли старый сертификат к прежней панели.

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

Шаг 12. Подготовьте режим финальной синхронизации

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

Варианты:

• временно включить maintenance mode на старом сайте;
• запретить оформление заказов на несколько минут;
• остановить cron и queue workers на старом сервере;
• сделать финальный дамп базы после остановки записи;
• выполнить финальный rsync файлов;
• переключить DNS сразу после финальной синхронизации;
• оставить старый сервер включенным на период наблюдения.

Для интернет-магазина, CRM и личного кабинета нельзя просто скопировать базу утром, а переключить DNS вечером. За это время появятся новые данные, которые останутся на старом сервере.

Шаг 13. Переключите DNS

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

Обычно меняют:

• A-запись основного домена на новый IPv4;
• A-запись www на новый IPv4;
• AAAA-запись, если используется IPv6;
• поддомены, если они тоже переезжают;
• API-домены и webhook-домены;
• служебные записи только если они действительно должны измениться.

Не меняйте все DNS-записи подряд. MX, SPF, DKIM, DMARC и почтовые записи трогать не нужно, если почта не переносится. Лишние изменения в DNS часто создают больше проблем, чем сам перенос сайта.

Шаг 14. Следите за двумя серверами после переключения

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

Проверьте на новом VPS:

• нагрузку CPU;
• использование RAM;
• свободное место на диске;
• логи Nginx или Apache;
• логи PHP-FPM или приложения;
• логи базы данных;
• ошибки 404, 500, 502, 503 и 504;
• скорость открытия страниц;
• отправку форм;
• новые заказы и заявки;
• работу cron-задач;
• работу webhook и API.

На старом сервере полезно смотреть access logs. Если туда еще идут пользователи, выключать его рано.

Шаг 15. Проверьте SEO и аналитику

После переноса сайт должен сохранить URL, редиректы, карту сайта, robots.txt и корректные HTTP-статусы. Ошибка на этом этапе может ударить по SEO сильнее, чем короткий технический простой.

Проверьте:

• главная страница отдает 200 OK;
• важные страницы отдают 200 OK;
• старые URL корректно редиректят на новые, если структура менялась;
• нет массовых 404;
• robots.txt доступен;
• sitemap.xml доступен;
• canonical URL не указывают на тестовый домен;
• HTTPS работает без ошибок;
• нет mixed content;
• аналитика и пиксели подключены;
• формы и цели в аналитике работают.

Если при тестировании использовался временный домен или staging, убедитесь, что он не попал в canonical, sitemap, robots.txt, Open Graph и внутренние ссылки.

Шаг 16. Подготовьте план отката

План отката нужен до переключения, а не после аварии. Если новый VPS неожиданно показывает критические ошибки, нужно быстро вернуть пользователей на старый сервер.

В плане отката должны быть:

• старый IP сервера;
• актуальные DNS-записи до миграции;
• backup базы данных;
• backup файлов;
• доступ к старому серверу;
• доступ к DNS-зоне;
• понимание, какие данные могли появиться на новом сервере;
• ответственный человек, который принимает решение об откате.

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

Отдельный чеклист для WordPress

• Сделайте backup файлов и базы данных.
• Перенесите wp-content, uploads, plugins и themes.
• Проверьте wp-config.php.
• Проверьте версию PHP и нужные расширения.
• Импортируйте базу данных на новый VPS.
• Проверьте siteurl и home в базе данных.
• Проверьте постоянные ссылки.
• Очистите кеш плагинов.
• Проверьте Redis или object cache, если он используется.
• Проверьте формы, SMTP и отправку писем.
• Проверьте админку и загрузку медиафайлов.
• Проверьте WooCommerce checkout, если есть магазин.
• Отключите maintenance mode после финального переключения.

Отдельный чеклист для Laravel или другого backend-проекта

• Перенесите код проекта.
• Проверьте .env.
• Установите зависимости composer или npm.
• Проверьте APP_KEY.
• Настройте права на storage и cache.
• Импортируйте базу данных.
• Выполните миграции только если это предусмотрено планом.
• Настройте queue workers.
• Настройте cron.
• Проверьте supervisor или systemd.
• Проверьте Nginx-конфиг.
• Проверьте API, webhooks и фоновые задачи.
• Отключите debug-режим в production.

Отдельный чеклист для интернет-магазина

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

Что нельзя делать при переносе сайта

• Менять DNS до проверки нового VPS.
• Переносить сайт без полного backup.
• Отключать старый сервер сразу после смены IP.
• Менять NS-записи без необходимости.
• Переносить только файлы и забывать базу данных.
• Копировать базу заранее и не делать финальную синхронизацию.
• Игнорировать SSL.
• Забывать cron, queue workers и фоновые процессы.
• Оставлять debug-режим включенным после переноса.
• Не проверять формы, почту и платежи.
• Удалять старый сервер до окончания периода наблюдения.
• Делать перенос в пиковое время трафика.

Сколько времени занимает перенос

Время зависит от размера сайта и сложности проекта. Небольшой сайт можно перенести быстро, если есть доступы и понятная структура. Большой WordPress, WooCommerce, CRM или Laravel-проект требует больше времени на тесты, финальную синхронизацию и проверку интеграций.

Больше всего времени обычно занимает не копирование файлов, а проверка: совместимость PHP, импорт базы, права доступа, SSL, формы, почта, платежи, cron, кеш и DNS. Именно проверка отличает нормальную миграцию от случайного переноса.

Как понять, что перенос прошел успешно

• Домен открывается с нового IP.
• HTTPS работает без ошибок.
• Главная и внутренние страницы открываются быстро.
• Админка работает.
• Формы отправляют письма.
• Новые заявки или заказы появляются на новом сервере.
• База данных пишет данные корректно.
• Файлы загружаются.
• Cron-задачи выполняются.
• Ошибки 500, 502, 503 и 504 не появляются массово.
• В логах нет критических ошибок.
• Старый сервер больше не получает значимый трафик.
• Backup на новом VPS настроен.

Когда можно выключать старый сервер

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

Перед отключением старого сервера проверьте:

• на старом сервере почти нет новых запросов в access logs;
• новые заявки и заказы приходят на новый VPS;
• DNS указывает на новый IP;
• почта работает корректно;
• webhooks работают;
• backup нового VPS настроен;
• у вас есть архив старого сайта и базы данных;
• прошел период наблюдения после переключения.

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

Почему перенос лучше делать на VPS с запасом

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

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

Почему xHost24 подходит для переноса сайта на VPS

xHost24 подходит для проектов, которым нужно перенести сайт на VPS в Европе без лишней бюрократии и с понятным техническим маршрутом. На сайте доступны VPS и Power VPS, NVMe, сеть 1 Gb/s, DDoS-защита, Linux, Windows, собственный ISO, IPv4-ресурсы и поддержка 24/7.

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

Если вы планируете перенести WordPress, WooCommerce, сайт компании, CRM, Laravel-проект, API или несколько сайтов, лучше заранее описать текущую схему: домен, текущий хостинг, размер файлов, размер базы данных, CMS, версию PHP, нужную локацию и желаемое время переключения. Так проще подобрать VPS и перенести проект без лишнего простоя.

Посмотреть доступные варианты VPS и Power VPS можно на сайте xHost24.

Практический чеклист перед миграцией

• Определите тип сайта и критичные функции.
• Соберите доступы к старому серверу, панели, DNS и базе данных.
• Зафиксируйте текущие DNS-записи.
• Снизьте TTL за 24–48 часов до миграции.
• Подберите VPS с запасом по CPU, RAM и диску.
• Подготовьте новый VPS до переключения домена.
• Сделайте полный backup файлов и базы данных.
• Перенесите файлы на новый сервер.
• Импортируйте базу данных.
• Настройте конфиги, env-файлы и подключения.
• Проверьте сайт через hosts-файл или временный домен.
• Проверьте SSL.
• Проверьте формы, почту, платежи, админку и webhooks.
• Остановите запись на старом сайте перед финальным дампом, если проект динамический.
• Сделайте финальную синхронизацию файлов и базы.
• Переключите DNS на новый IP.
• Следите за логами и нагрузкой.
• Оставьте старый сервер включенным на период наблюдения.
• Настройте регулярный backup на новом VPS.
• Отключайте старый сервер только после проверки всех функций.

Практический ориентир для владельца проекта

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

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

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