Миграция большого WordPress без простоя: пошаговый план

Большой WordPress-сайт можно перенести на новый сервер без заметного простоя, но не одной кнопкой «скопировать всё». Пока вы переносите файлы, на старом сервере появляются новые заказы, комментарии и изображения; если перенести только базу или включить maintenance mode на несколько часов, часть данных потеряется. Рабочая схема для WordPress 6.x — заранее собрать копию, синхронизировать изменяемые данные, переключить трафик в короткое окно и оставить старый сервер доступным до завершения проверки.

Что считать «без простоя»

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

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

Главный риск миграции — не потеря файлов, а появление двух версий сайта, которые принимают записи независимо друг от друга.

Какая схема подходит вашему сайту

Ниже — практический вариант с коротким окном блокировки записей. Он рассчитан на WordPress 6.x, WP-CLI актуальной ветки 2.x, PHP-версию, поддерживаемую вашей версией WordPress, и MySQL или MariaDB. Точные версии PHP и СУБД проверьте в требованиях используемой версии WordPress и ваших плагинов.

Подготовка до копирования

Сначала составьте карту того, что должно переехать. В типичном проекте это каталог WordPress, база данных, каталог wp-content/uploads, настройки веб-сервера, сертификаты, задания cron, переменные окружения и внешние интеграции.

• Создайте отдельную учётную запись администратора на новом сервере и проверьте SSH-доступ.
• Установите ту же версию PHP и те же расширения, что на старом сервере. Различия в PHP могут проявиться только при оформлении заказа или запуске cron.
• Проверьте версии WordPress, темы и плагинов. Не обновляйте всё одновременно с миграцией: иначе вы не отличите проблему переноса от несовместимости обновления.
• Снизьте TTL DNS-записей заранее. Это не ускорит уже закешированные ответы у всех провайдеров, поэтому старый сервер нельзя выключать сразу после смены адреса.
• Сделайте резервные копии базы и файлов. Скачайте хотя бы одну копию за пределы обоих серверов и проверьте, что архив можно открыть.

До начала работ запишите текущие показатели: размер базы, объём uploads, количество записей за час, время ответа главных страниц и список фоновых задач. Без этого после миграции легко принять неполную копию за успешную.

Пошаговый перенос

1. Подготовьте новый сервер, но не направляйте на него пользователей

Создайте виртуальный хост, базу данных, пользователя БД и каталог сайта. Установите WordPress-файлы той же версии, но не запускайте установку через браузер: базу нужно перенести со старого сервера.

Скопируйте конфигурацию веб-сервера с адаптацией путей и прав доступа. Проверьте, что процесс PHP может читать файлы WordPress, а веб-сервер не открывает каталог резервных копий и служебные файлы.

Проверка: временный домен или локальная запись hosts открывает новый сервер, а PHP и соединение с пустой базой работают без ошибок. Публичный домен по-прежнему обслуживает старый сервер.

2. Перенесите базу и файлы в первый проход

Экспортируйте базу штатным инструментом вашей СУБД или WP-CLI. Для крупной базы заранее проверьте свободное место: временный SQL-файл может быть сопоставим с размером базы.

wp db export /var/backups/wordpress-initial.sql
rsync -aH --delete /var/www/old-site/wp-content/uploads/ new-server:/var/www/new-site/wp-content/uploads/

Команды приведены для Linux и WP-CLI; пути замените на свои. Не копируйте таким способом файл с паролем или токеном в командной строке. Если сайт использует медиа вне wp-content/uploads, перенесите и эти каталоги отдельной проверенной командой.

Импортируйте дамп в новую базу, затем на тестовом адресе выполните поиск старого URL с пробным запуском:

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --dry-run

Не заменяйте URL вслепую. WP-CLI умеет обрабатывать сериализованные данные, но результат всё равно нужно проверить на копии базы. Поле guid обычно не меняют: это идентификатор записи, а не настройка адреса страницы.

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

3. Сделайте второй проход синхронизации

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

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

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

4. Проведите короткое окно переключения

1. Остановите фоновые задания WordPress на старом сервере или временно отключите запускающий их cron. Иначе импорт может продолжаться во время переноса.
2. Включите режим, который блокирует новые записи: maintenance mode, ограничение на уровне приложения или временную страницу только для операций записи. Перед этим предупредите команду поддержки и операторов заказов.
3. Сделайте финальный экспорт базы и импортируйте его на новый сервер. Если база большая, измерьте эту операцию заранее на копии.
4. Повторите синхронизацию uploads с флагом удаления только после проверки путей. Ошибка в пути вместе с --delete может удалить не тот каталог.
5. Поменяйте конфигурацию балансировщика или DNS. Предпочтительнее переключать origin на уже проверенный новый сервер; при одном DNS учтите кэширование.
6. Откройте запись сайта на новом сервере, запустите фоновые задания и снимите режим блокировки записей только после проверки базы.

Проверка: новый сервер получает запросы, создаёт тестовую запись, отправляет письмо, показывает свежие изображения и не возвращает ошибки 500 или 502. Тестовую запись удалите по принятой процедуре.

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

• Авторизацию, восстановление пароля и права разных ролей.
• Корзину, оформление заказа, оплату и вебхуки платёжных сервисов.
• Загрузку файлов, генерацию миниатюр и доступ к приватным документам.
• Канонические URL, редиректы, robots.txt, sitemap и ссылки в письмах.
• Запуск cron, очереди плагинов, отправку почты и интеграции с CRM.
• Логи веб-сервера, PHP и базы, а также время ответа и долю ошибок.

Проверяйте сайт с несколькими заголовками Host и из внешней сети: локальный тест через hosts может скрыть проблему DNS, CDN или TLS-сертификата. Сравните несколько реальных URL со старым сервером, пока он ещё доступен.

Что обычно ломается

URL изменился частично

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

Заказы появились на старом сервере

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

На новом сервере 502 или белый экран

Сравните версию PHP, расширения, лимиты памяти, права на файлы и журнал PHP-FPM. Один из плагинов может использовать расширение, которого нет на новом сервере. Откатите origin на старый сервер, если проверка показывает, что новый не готов.

Сайт открывается, но фоновые задачи не работают

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

Где этот план не подходит

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

Кэширование — отдельная тема: перед переключением очистите кэш приложения, reverse proxy и CDN по правилам конкретной инфраструктуры. Не удаляйте кэш до создания новой копии, если он нужен для диагностики.

Что делать дальше

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

Термин: origin — исходный сервер, с которого CDN или балансировщик получает контент. Смена origin обычно быстрее смены DNS, но не решает проблему несинхронизированной базы.