Что следует учитывать при переходе к другому провайдеру веб-хостинга

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

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

Этап 1: Проведите аудит текущей среды хостинга, прежде чем что-либо менять

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

Профилирование трафика и ресурсов

Получите данные о ресурсах сервера как минимум за 90 дней — не только количество просмотров страниц. Важны следующие метрики:

• Пиковые одновременные подключения — не средний трафик, а максимальный пик, который должен выдержать ваш сервер
• Потребление памяти на один PHP-воркер или процесс приложения
• Паттерны дискового I/O — особенно важны при использовании приложений с интенсивной работой с базами данных, таких как WooCommerce или пользовательская CRM
• Использование пропускной способности — ежемесячный объём передачи данных в сравнении с лимитом вашего текущего тарифа

Если ваш текущий хостинг предоставляет cPanel или Plesk, эти данные доступны в разделах использования ресурсов или AWStats. На Linux VPS выполните следующую команду для получения базового снимка состояния:

vmstat 1 10
iostat -x 1 5
free -m
df -h

Этот вывод покажет, является ли узким местом CPU, RAM или диск — что напрямую определяет, нужен ли вам более крупный тариф на общем хостинге, VPS или Выделенный сервер.

Инвентаризация программного стека

Задокументируйте каждый компонент вашего стека с точными номерами версий:

• Версия PHP (например, 8.1, 8.2) и активные расширения (mbstring, curl, gd, imagick, redis)
• Версия MySQL или MariaDB и движок хранилища (InnoDB vs. MyISAM важны для инструментов миграции)
• Программное обеспечение веб-сервера: Apache, Nginx, LiteSpeed или комбинация с обратным прокси
• Любые скомпилированные модули, пользовательские правила .htaccess или блоки nginx.conf location
• Задания Cron — экспортируйте их из crontab -l и задокументируйте отдельно
• Тип и издатель SSL-сертификата (Let’s Encrypt, коммерческий CA, wildcard)

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

Этап 2: Оцените и выберите правильный уровень хостинга

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

Сравнение уровней хостинга

Ключевое правило выбора: Если ваше приложение требует специфической конфигурации пула PHP-FPM, подключений через Redis-сокет, пользовательских правил перезаписи Nginx или любого демон-процесса, общий хостинг архитектурно несовместим. Вам необходим как минимум VPS с root-доступом.

Для сайтов на WordPress или Joomla с умеренным трафиком VPS с cPanel обеспечивает привычный интерфейс панели управления, сохраняя при этом изоляцию и производительность виртуальной машины.

Критерии оценки провайдера

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

• SLA по доступности с пунктами о финансовых штрафах — SLA на уровне 99,9% без компенсации не имеет смысла
• Рейтинг уровня дата-центра (Tier III или Tier IV для производственных нагрузок)
• Сетевая избыточность — BGP multi-homing, несколько вышестоящих провайдеров
• Тип хранилища — NVMe SSD против SATA SSD против вращающихся дисков (различия в задержке существенны)
• Политика резервного копирования — частота, срок хранения, хранятся ли резервные копии вне площадки
• SLA времени ответа поддержки — различайте время первого ответа и время решения проблемы

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

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

Что должна включать полная резервная копия

• Файлы корневого каталога веб-сервера — весь корневой каталог документов, включая скрытые файлы, такие как .htaccess и .env
• Все базы данных — экспортированные в виде дампов .sql, а не просто копия каталога базы данных
• Данные электронной почты — если вы используете Почтовый хостинг, привязанный к вашему домену, экспортируйте почтовые ящики до любых изменений DNS
• Задания Cron — crontab -l > crontab_backup.txt
• SSL-сертификаты и закрытые ключи — при использовании коммерческого сертификата экспортируйте полную цепочку
• Файлы конфигурации сервера — /etc/nginx/, /etc/apache2/, /etc/php/, пользовательские настройки my.cnf

Выполнение экспорта базы данных

Для MySQL/MariaDB используйте mysqldump с параметрами, обеспечивающими полную точность:

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

Флаг --single-transaction критически важен для таблиц InnoDB — он создаёт согласованный снимок без блокировки таблиц, что означает, что ваш живой сайт продолжает обслуживать запросы во время дампа.

Проверка целостности резервной копии

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

Резервная копия, восстановление которой вы не тестировали, — это не резервная копия, а ложное чувство безопасности.

Этап 4: Проверьте совместимость на целевом сервере

Прежде чем переносить производственные данные, разверните новую среду и проверьте совместимость с помощью промежуточного подхода.

Проверка версии PHP и расширений

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

Сравните этот вывод с инвентаризацией из Этапа 1. Любое отсутствующее расширение должно быть установлено до миграции, а не после.

Проверка совместимости базы данных

При миграции с MySQL 5.7 на MySQL 8.0 (распространённый сценарий) обратите внимание на следующие критические изменения:

• Кодировка utf8mb3 устарела; для столбцов может потребоваться явное объявление кодировки
• Поведение GROUP BY изменилось — запросы, работавшие в 5.7, могут завершаться ошибкой в 8.0 без корректировки режима ONLY_FULL_GROUP_BY
• NO_ZERO_DATE включён по умолчанию в строгом режиме, что отклоняет поля дат, содержащие 0000-00-00

Протестируйте ваш SQL-дамп на целевой версии MySQL перед переключением производственного трафика.

Перевод конфигурации веб-сервера

При миграции с Apache на Nginx (частый сценарий при переходе на производительно-оптимизированный VPS) ваши правила .htaccess не транслируются автоматически. Распространённые преобразования:

Перенаправление Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Эквивалент Nginx в блоке server:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Пропуск этого преобразования — одна из наиболее распространённых причин ошибок 404 и петель перенаправления после миграции.

Этап 5: Выполните миграцию с минимизацией времени простоя

Стратегически выберите окно для миграции

Проанализируйте Google Analytics или журналы сервера, чтобы определить окно с наименьшим трафиком — как правило, с 02:00 до 05:00 по часовому поясу основной аудитории во вторник или среду. Избегайте пятниц: если что-то пойдёт не так, ваши возможности получить поддержку существенно сузятся на выходных.

Рабочий процесс миграции с предварительным промежуточным этапом

1. Направьте поддомен на новый сервер (например, staging.example.com) с помощью A-записи, не затрагивая производственный DNS
2. Перенесите все файлы и базы данных на новый сервер
3. Обновите строку подключения к базе данных приложения, чтобы она указывала на новую базу данных
4. Измените локальный файл /etc/hosts, чтобы производственный домен разрешался в IP-адрес нового сервера — это позволяет тестировать полную производственную конфигурацию без влияния на живых пользователей:

# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com

1. Проведите полное функциональное тестирование — каждую форму, платёжный процесс, систему входа, конечную точку API и загрузку медиафайлов
2. Запустите тесты производительности с помощью ab (Apache Benchmark) или wrk:

ab -n 1000 -c 50 https://example.com/

1. Только после прохождения всех тестов переходите к переключению DNS

Настройка SSL-сертификата

Убедитесь, что SSL-сертификат установлен и проверен на новом сервере до переключения DNS. При использовании Let’s Encrypt:

certbot --nginx -d example.com -d www.example.com

При использовании коммерческого сертификата от провайдера, например доступного через SSL-сертификаты, установите полную цепочку сертификатов (сертификат + промежуточный CA + корневой CA), чтобы избежать ошибок проверки цепочки на старых клиентах.

Этап 6: Переключение DNS — наиболее технически чувствительный шаг

Распространение DNS широко понимается неправильно. Цифра в 48 часов — это максимальный предел в худшем случае, а не типичная продолжительность. На практике большинство резолверов соблюдают значение TTL изменяемой записи.

Снижение TTL перед переключением

Как минимум за 24–48 часов до окна миграции уменьшите TTL ваших A-записей и CNAME-записей до 300 секунд (5 минут):

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

Это означает, что после обновления записи на новый IP старое кэшированное значение истечёт в течение 5 минут для большинства резолверов — а не через 48 часов. Это наиболее эффективная техника для минимизации окна распространения DNS.

Обновление серверов имён vs. A-записей

Существует два различных подхода к переключению DNS:

• Изменение только A-записей (при сохранении тех же авторитетных серверов имён): Распространение следует TTL записи. Наиболее быстрый подход, если ваш регистратор домена допускает прямое управление записями.
• Изменение серверов имён (указание на DNS нового хостинга): TTL серверов имён обычно составляет 24–48 часов и не находится под вашим прямым контролем. Этот подход занимает больше времени.

По возможности предпочитайте обновление A-записей. Управляйте DNS вашего домена через панель управления Регистрации доменов для прямого контроля на уровне записей.

Сохранение активности старого сервера в период распространения

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

Этап 7: Мониторинг и проверка после миграции

Мониторинг доступности и производительности

Настройте внешний мониторинг доступности сразу после переключения DNS — не после того, как вы считаете распространение завершённым. Инструменты для развёртывания:

• UptimeRobot или Better Uptime — HTTP(S)-проверки каждые 1–5 минут из нескольких географических точек
• Google Search Console — следите за отчётами об охвате и Core Web Vitals на предмет аномалий в течение 7 дней после миграции
• New Relic или Datadog — мониторинг производительности на уровне приложения, если это оправдано вашим приложением

Выявление и устранение ошибок после миграции

Немедленно выполните сканирование нового сайта с помощью Screaming Frog или зеркала wget:

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

Распространённые проблемы после миграции и их причины:

Исправление жёстко закодированных URL в базах данных WordPress

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

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

Флаг --precise корректно обрабатывает сериализованные данные PHP, которые наивная замена строк нарушает.

Этап 8: Отмените старый хостинг-план

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

• Распространение DNS завершено (проверьте с помощью dig +trace example.com из нескольких точек)
• Мониторинг доступности показывает 100% работоспособность в течение не менее 72 последовательных часов
• В журналах сканирования не обнаружено ошибок 404 или неработающих ссылок
• Доставка электронной почты корректно функционирует на новом сервере
• Аналитика показывает нормальные паттерны трафика без аномальных падений
• У вас есть локальная копия всех файлов резервных копий, независимая от обоих хостинг-провайдеров

Технический контрольный список ключевых выводов

Используйте это как контрольный список выполнения миграции:

До миграции

• [ ] Экспортирован базовый показатель использования ресурсов за 90 дней (CPU, RAM, I/O, пропускная способность)
• [ ] Задокументирован полный программный стек с точными номерами версий
• [ ] TTL DNS снижен до 300 секунд как минимум за 24 часа до переключения
• [ ] Создана и протестирована полная резервная копия (файлы + базы данных + задания cron + электронная почта)
• [ ] Проверены версия PHP и все необходимые расширения на целевом сервере
• [ ] Правила .htaccess переведены в формат Nginx при смене веб-сервера
• [ ] SSL-сертификат установлен и проверен на новом сервере до изменения DNS

Во время миграции

• [ ] Файлы перенесены с помощью rsync с проверкой контрольных сумм (rsync -avz --checksum)
• [ ] База данных импортирована и проверено соответствие количества строк источнику
• [ ] Полная функциональность сайта протестирована через переопределение /etc/hosts до изменения DNS
• [ ] Обновлены файлы конфигурации приложения (хост базы данных, учётные данные, URL сайта)

После миграции

• [ ] Внешний мониторинг доступности активирован в течение 5 минут после переключения DNS
• [ ] Старый сервер работает не менее 72 часов после переключения
• [ ] Выполнено полное сканирование сайта; все ошибки 404 и неработающие ссылки устранены
• [ ] Жёстко закодированные URL исправлены в базе данных (особенно для WordPress)
• [ ] Google Search Console отслеживается в течение 7 дней после миграции
• [ ] Старый хостинг-план отменён только после подтверждения всех вышеуказанных пунктов

Часто задаваемые вопросы

Сколько времени фактически занимает распространение DNS и можно ли его ускорить?

Продолжительность распространения DNS определяется значением TTL изменяемой записи, а не фиксированным окном в 48 часов. Если вы уменьшите TTL вашей A-записи до 300 секунд как минимум за 24 часа до миграции, большинство резолверов подхватят новый IP в течение 5–10 минут после изменения. Цифра в 48 часов применима к изменениям делегирования серверов имён, TTL которых находится вне вашего контроля.

Повлияет ли миграция на новый хостинг на позиции моего сайта в Google?

Правильно выполненная миграция без простоев, с сохранённой структурой URL и действительным SSL не оказывает негативного влияния на SEO. Позиции могут временно снизиться, если новый сервер работает медленнее, если URL изменились без надлежащих перенаправлений 301 или если сайт был недоступен во время сканирования. Отслеживайте отчёты об охвате и Core Web Vitals в Google Search Console в течение 14 дней после миграции.

Каков наиболее безопасный способ переноса больших баз данных без повреждения данных?

Используйте mysqldump с флагом --single-transaction для таблиц InnoDB, чтобы обеспечить согласованный снимок без блокировки таблиц. Передавайте файл дампа по SSH с помощью scp или rsync, а не через phpMyAdmin, который имеет ограничения по размеру файла и тайм-ауты, вызывающие незаметное усечение больших баз данных.

Нужно ли переустанавливать SSL-сертификат после миграции?

Да. SSL-сертификаты привязаны к закрытому ключу сервера, который находится на исходном сервере. Вы должны либо перевыпустить сертификат на новом сервере (бесплатно для Let’s Encrypt), либо экспортировать закрытый ключ и цепочку сертификатов со старого сервера и установить их на новом. Убедитесь, что сертификат полностью проверен до обновления DNS, чтобы HTTPS работал сразу после переключения.

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

Выполните dig +trace example.com @8.8.8.8 и dig +trace example.com @1.1.1.1, чтобы убедиться, что резолверы Google и Cloudflare возвращают IP-адрес нового сервера. Проверяйте мониторинг доступности в течение 72 последовательных часов чистых ответов. Выполните сканирование сайта на ошибки 404 и проверьте доставку электронной почты. Только после прохождения всех этих проверок безопасно завершать работу старого хостинг-аккаунта.