Пять ошибок при переносе сайта на новый сервер

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

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

Отсутствие полной резервной копии

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

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

Практический минимум для безопасной миграции выглядит так:

• полный архив файлов сайта и каталога загрузок;
• дамп базы данных с указанием кодировки и версии СУБД;
• копии конфигураций PHP, Nginx или Apache;
• сохранённые ключи доступа, сертификаты и DNS-параметры;
• отдельная резервная копия почтовых ящиков и важных документов.

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

Перенос без учёта окружения

Вторая проблема возникает, когда копируют сайт, но не воспроизводят серверное окружение. CMS и веб-приложение зависят от версии PHP, расширений, СУБД, системных библиотек, настроек веб-сервера и правил обработки запросов. Новый сервер может быть мощнее прежнего, однако несовместимость программных компонентов вызовет белый экран, ошибки 500 или некорректную работу отдельных функций.

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

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

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

Неподготовленная смена DNS

Третья ошибка связана с DNS-записями и неправильным планированием переключения. Изменение A-записи не происходит мгновенно для всех пользователей: результат зависит от времени жизни записи в кэше, настроек провайдеров и локальных DNS-серверов. В течение переходного периода часть посетителей может попадать на старый сервер, а часть — на новый.

За несколько дней до миграции стоит уменьшить TTL основных записей домена. Это ускорит обновление адресов после переключения, хотя не отменит все задержки. Заранее проверяют A-записи, записи для поддоменов, MX для почты, SPF, DKIM и DMARC. Если на сайте используются отдельные адреса для API, изображений или панели управления, их также включают в план переноса.

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

До переключения полезно заранее составить последовательность действий:

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

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

Игнорирование безопасности и сертификатов

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

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

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

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

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

Регулярный мониторинг помогает заметить подозрительную активность уже после запуска. Для бизнеса, где серверная инфраструктура связана с офисной сетью, учётными программами или удалёнными сотрудниками, разумно привлекать специалистов по системному администрированию. Комплексное сопровождение, включая настройку серверов и техническую поддержку, можно организовать через ИТ-партнёра VINCIT.

Отсутствие проверки после запуска

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

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

Полезно сравнить показатели старого и нового сервера: время ответа, скорость загрузки, использование процессора и памяти, количество ошибок в журналах. Веб-мастерские инструменты покажут, появились ли проблемы с индексацией, robots.txt, XML-картой сайта и каноническими адресами. Если менялась структура URL, настраивают постраничные 301-редиректы, чтобы сохранить поисковый трафик.

В первые дни после запуска контролируют:

• доступность домена и основных поддоменов;
• ошибки 4xx и 5xx в логах веб-сервера;
• работу почты, форм, API и уведомлений;
• корректность заказов и записей в базе данных;
• скорость страниц с компьютеров и мобильных устройств.

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

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