Нулевая недоступность при смене провайдера остаётся классической задачей для админов и девопсов. Эта статья — практичный чек‑лист миграции сайта на новый хостинг без простоя: от подготовки окружения и снижения DNS TTL до финального переключения и пост‑проверок. Внутри — рабочие команды rsync и mysqldump, порядок действий, контрольные точки и частые ошибки. Формат подходит для популярных CMS (WordPress, Bitrix, Joomla, OpenCart) и кастомных PHP/Node.js‑приложений.
Цели и подход: что считаем «без простоя»
Под «без простоя» будем понимать отсутствие заметной недоступности для большинства пользователей в момент переключения. Полностью избежать паузы при записи данных сложно без репликации БД на уровне СУБД, но минимизировать окно до минут при корректной подготовке вполне реально. Ключевые принципы: заранее уменьшить DNS TTL, сначала выполнить черновую синхронизацию файлов, протестировать новый стенд через hosts, затем сделать краткую «заморозку» изменений (или частичную read‑only), дельта‑синхронизацию и переключить DNS.
Инвентаризация и подготовка
Начинайте с инвентаризации. Ваша задача — понять, какие компоненты задействованы сейчас и что должно быть доступно на новом хостинге: версия PHP и handler (FPM/LSAPI), активные расширения (intl, mbstring, gd, imagick, zip), лимиты (memory_limit, upload_max_filesize, post_max_size, max_execution_time), версии СУБД (MySQL/MariaDB/PostgreSQL), веб‑сервер (Nginx/Apache), планировщики (cron или wp-cron), фоновые очереди, расширения кэша (Redis/Memcached), хранилища сессий, интеграции (платёжные шлюзы, SMS, SMTP), доменные записи (A/AAAA, CNAME, MX, SPF, DKIM, DMARC), CDN и WAF, SSL/сертификаты.
Соберите минимальные требования проекта и воспроизведите их на новом хостинге: создайте пользователей и базы, включите нужные PHP‑модули, подготовьте виртуальные хосты, проверьте корректность прав на файлы и каталоги, создайте пустую директорию для деплоя и логов. Если переезд на новый виртуальный хостинг или на VDS — заранее убедитесь, что конфигурации соответствуют текущему продакшену.
Снижаем DNS TTL заранее
Минимизировать задержки при переключении помогает управление DNS TTL. За 24–72 часа до миграции уменьшите TTL для A/AAAA/CNAME записей основного домена и критичных поддоменов до 60–300 секунд. Это даст возможность быстро «переучить» кэширующие резолверы в день Х. Учтите, что некоторые публичные резолверы и мобильные сети могут игнорировать заниженный TTL, поэтому полностью мгновенной смены не обещайте — оставьте старый хостинг работающим минимум 24–48 часов после переключения. Если зоной управляете через регистрацию доменов, проверьте, что права на изменения и NS‑делегирование у вас под рукой.
Важно: если у вас включён CDN, проверьте, где именно меняется
TTL— у CDN или в вашем авторитативном DNS. Для доменов с DNSSEC убедитесь, что ключи и подписи не пострадают при переключении зон.
План миграции и критерии успеха
Определите окно: когда на сайте минимальный трафик и меньше всего транзакций. Сформулируйте чек‑лист критериев успешного переключения: сайт открывается по HTTPS, административная панель доступна, формы и загрузки работают, фоновые задачи исполняются, логи чистые, скорость не ниже прежней, SEO‑страницы и карта сайта доступны.
Обязательно составьте план отката: как быстро вернуть трафик на старый хостинг (обратное изменение DNS и/или временный CNAME), где лежат резервные копии, кто по ролям отвечает за БД, веб‑сервер, почту и домен.
Бэкапы: без них никуда
Перед началом сделайте полный backup файлов и базы. Это must‑have даже если план идеален. Храните резервные копии отдельно от рабочих серверов, подписывайте датой и проверяйте, что архивы читаются.
Экспорт БД через mysqldump
Для MySQL/MariaDB используйте mysqldump с параметрами, обеспечивающими консистентность и полноту. Для InnoDB достаточно --single-transaction без блокировок таблиц, для MyISAM потребуется --lock-tables. Добавьте выгрузку триггеров и процедур.
mysqldump \
-h db-old.example \
-u dbuser -p'SECRET' \
--single-transaction \
--routines --triggers --events \
--default-character-set=utf8mb4 \
--set-gtid-purged=OFF \
mydatabase | gzip > /backups/db-$(date +%F-%H%M).sql.gz
Проверьте итоговый размер архива и наличие в дампе критичных таблиц. При больших БД используйте сжатие и утилиты вроде pv для мониторинга скорости, а также убедитесь, что на новом хостинге выставлены подходящие max_allowed_packet и innodb_log_file_size.
Файлы — первая синхронизация rsync
Сначала синхронизируйте файлы «на горячую», пока сайт работает. Исключайте временные каталоги, кэши и логи — так ускорите копирование и не загрязните новый стенд.
rsync -azvh --progress \
--delete-delay \
--exclude='.git' --exclude='cache/' --exclude='tmp/' --exclude='logs/' \
-e 'ssh -o Compression=yes' \
user@old-host:/var/www/site/ /var/www/site/
--delete-delay безопаснее, чем мгновенное удаление, и позволяет сначала перенести новые файлы. Если на старом сервере задействованы ACL или нестандартные права, добавьте -A/-X для сохранения атрибутов и расширенных прав.
Подготовка окружения на новом хостинге
Создайте пустую базу и пользователя с минимально необходимыми правами. В веб‑сервере опишите виртуальный хост с корректным server_name, включите HTTPS и настройте редиректы www/non‑www. Проверьте PHP‑параметры: memory_limit не меньше прежнего, upload_max_filesize и post_max_size достаточны для загрузок, opcache включён, date.timezone корректен. Если поднимаете всё на VDS, заранее выберите панель администрирования и сравните функциональность — полезна шпаргалка по панелям: что выбрать в 2025.
Если проект собирается (Composer/NPM), выполните сборку на новом сервере, не трогая боевую директорию. Для Composer используйте --no-dev и --optimize-autoloader, для фронта — кэшируйте зависимости. Важно добиться идентичности версий (PHP, Node, расширения), иначе возможны «плавающие» баги.
Импорт БД на новом сервере
Разверните дамп, убедившись, что кодировка базы совпадает со старой. Для больших дампов включите сжатый импорт через zcat или gunzip -c.
gunzip -c /backups/db-last.sql.gz | \
mysql -h 127.0.0.1 -u dbuser -p'SECRET' mydatabase
Следом проверьте наличие процедур и событий, сопоставьте привилегии пользователя и убедитесь, что параметры sql_mode и time_zone не отличаются от старой инсталляции критично для приложения.
Правка конфигов приложения
Подготовьте конфиги под новое окружение: данные подключения к базе, пути, SMTP. Для WordPress изменяются параметры в wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST), для приложений на Laravel — переменные .env, для Bitrix — dbconn.php. Не храните секреты в репозитории — используйте переменные окружения и защищённые хранилища.
Тестирование через hosts: смотрим сайт на новом IP
Прежде чем трогать DNS, протестируйте сайт, «подменив» резолвинг только на своей машине. Добавьте строку с новым IP и доменом в /etc/hosts (Linux/macOS) или C:\\Windows\\System32\\drivers\\etc\\hosts (Windows), затем обновите кэш DNS у клиента и браузера. Так вы увидите сайт с нового хостинга, тогда как пользователи останутся на старом.
# пример для *nix
sudo sh -c 'echo "203.0.113.10 example.com www.example.com" >> /etc/hosts'
Пройдитесь по ключевым сценариям: вход в админку, отправка форм, загрузка файлов, построение миниатюр, оформление заказа, оплаты в песочнице, генерация карты сайта, обработка крон‑задач. Проверьте ошибки в логах PHP и веб‑сервера, а также метрики производительности. Убедитесь, что SSL‑сертификат корректен и цепочка полная, а редиректы HTTP→HTTPS на месте и не образуют циклов.
Если проект зависит от внешних callback‑ов (платёжные шлюзы, OAuth), чтобы не «стрельнуть» в прод, используйте тестовые ключи или временный поддомен, на который переключите только сами себя через hosts.
Финальное окно: заморозка, дельта‑синхронизация, переключение
Чтобы исключить потерю данных, в момент Х на короткое время «заморозьте» изменяемые сущности: закройте административную часть или переведите проект в краткий режим обслуживания, запретите новые публикации и комментарии. В интернет‑магазинах старайтесь выбрать окно с минимальными заказами.
Дельта‑rsync и свежий дамп БД
Сделайте повторный rsync — он подтянет изменившиеся файлы. Затем снимите свежий дамп БД и импортируйте его на новый сервер, заменив предыдущий. Это сведёт рассинхронизацию к секундам.
rsync -azvh --delete-delay \
--exclude='.git' --exclude='cache/' --exclude='tmp/' --exclude='logs/' \
user@old-host:/var/www/site/ /var/www/site/
mysqldump -h db-old -u dbuser -p'SECRET' \
--single-transaction --routines --triggers --events \
mydatabase | gzip > /backups/db-final.sql.gz
gunzip -c /backups/db-final.sql.gz | mysql -u dbuser -p'SECRET' mydatabase
После импорта быстро проверьте критичные таблицы и обновите кэш/перегенерацию, если это требуется вашей CMS. Для WordPress полезно сбросить пермалинки и пересоздать кэш миниатюр, для Bitrix — прогреть композитный кэш.
Переключаем DNS
Когда новый сайт готов, меняйте A/AAAA (или CNAME) записи на новый IP. Благодаря заранее заниженному TTL трафик начнёт перетекать в течение нескольких минут. Контролируйте реальную делегацию: используйте dig/nslookup с указанием авторитативных NS и публичных резолверов, проверяйте, что ответы возвращают новый адрес.
dig +short A example.com @8.8.8.8
dig +short A example.com @1.1.1.1
dig +trace example.com
Старый сервер не выключайте минимум 24–48 часов — часть пользователей ещё может видеть старый IP из‑за кэшей в сетях операторов. Если у вас IPv6, не забудьте обновить AAAA.
Пост‑проверки: что посмотреть сразу после переключения
Сразу контролируйте логи новых инстансов: ошибки PHP, медленные запросы MySQL, коды ответа веб‑сервера. Проверьте время отклика главной, страницу поиска, карточки товара, корзину, личный кабинет. Снимите профилирование под нагрузкой, убедитесь, что CPU/IO/сеть в норме.
Проверьте SSL: срок действия, SNI, промежуточные сертификаты. Удостоверьтесь, что включены современные протоколы и шифры, а редиректы не ведут на старый домен. Подробно про 301, HSTS и цепочку сертификатов — в материале о миграции домена и HTTPS. Если нужен выпуск или продление — смотрите SSL-сертификаты.
DNS и почта
Если почтовая инфраструктура тоже переехала, актуализируйте записи MX, SPF, DKIM, DMARC. Проверьте обратную PTR для исходящей почты и согласованность HELO/EHLO. Измерьте доставляемость через внешние тесты, чтобы не получить блокировки у провайдеров.
Производительность и тонкая настройка
Сразу задайте оптимальные лимиты PHP и веб‑сервера. Для Nginx проверьте client_max_body_size, буферы, сжатие, кэш статики; для PHP‑FPM — параметры пула (pm, pm.max_children, pm.max_requests). Включите и настройте opcache, проверьте JIT при необходимости. Для БД — размеры буферов InnoDB, журналов, кэш запросов (если актуален), лимиты соединений.
Если приложение активно пишет на диск (кэш, сессии, загрузки), убедитесь, что у каталога есть быстрый storage и корректные права, а каталог временных файлов не забивает корень ФС. Продумайте резервирование: автоматические ежедневные бэкапы файлов и БД, offsite‑копии и периодическую проверку восстановления.
Типичные проблемы и быстрые решения
Белый экран или 500 после переезда обычно вызваны несовместимой версией PHP или отсутствующими расширениями. Сравните phpinfo() на старом и новом сервере, подтяните нужные модули. Сбои загрузки файлов — проверьте upload_max_filesize, post_max_size, client_max_body_size и права на каталог загрузок. Медленные страницы — посмотрите медленные запросы (slow_query_log), индексы, кэширование. Проблемы с кодировкой — убедитесь, что база и соединение используют utf8mb4.
Отсутствуют картинки или 404 на статике — проверьте root и try_files в конфиге Nginx/Apache, а также что все симлинки и права перенесены. Цикл редиректов HTTP↔HTTPS — посмотрите правила в .htaccess или конфиге Nginx, не дублируйте редиректы на разных уровнях. Некорректная работа крона — убедитесь, что задания перенесены и имеют правильные пути/переменные окружения.
Особенности CMS: пару нюансов
WordPress: проверьте wp-config.php, соли, права на wp-content/uploads, перегенерацию миниатюр, постоянные ссылки. Если домен менялся, выполните поиск‑замену URL в БД аккуратно, учитывая сериализацию. Bitrix: убедитесь в совместимости с версией PHP, настройте opcache, проверьте dbconn.php и права на bitrix/tmp, прогрейте композит. Joomla/OpenCart: обратите внимание на configuration.php/config.php и пути к логам/кэшу.
Автоматизация и безопасность
Соберите сценарии миграции в один исполняемый скрипт: экспорт БД, rsync, импорт, очистка кэша, smoke‑тесты. Используйте SSH‑ключи с ограничениями, агент и мультиплексирование для ускорения. Логи и артефакты складывайте в отдельную директорию, чтобы при повторном прогоне можно было быстро сравнить результаты. Храните пароли и токены в менеджерах секретов, включите двухфакторную аутентификацию, ограничьте доступ по IP, минимизируйте привилегии сервисных пользователей.
План отката
Если что‑то пошло не так: не паниковать. До истечения «старого» TTL можно быстро вернуть трафик обратно, поменяв DNS на прежний IP. Параллельно раскатайте резервные копии в тестовое окружение и локализуйте причину. В идеале у вас есть набор команд «отката»: восстановление файлов, дампа БД, возврат старых конфигов. Документируйте инцидент: что сломалось, как починили, как предотвратить повторение.
Итоги
Миграция сайта без простоя — это дисциплина, а не магия. Заранее уменьшили dns ttl, сделали проверенные backup, перенесли файлы rsync, выгрузили БД через mysqldump, протестировали через hosts, провели дельта‑синк, переключили DNS и мониторите. Следуя этому чек‑листу, вы сведёте риски к минимуму, а пользователи даже не заметят переезда.
