Как восстановить WordPress из бэкапа Beget на другом хостинге

Blog image

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

На какие хостинги можно перенести восстановленный WordPress

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

Для сравнения виртуального хостинга используйте текущий порядок подборки сайта: Timeweb, МакХост, SpaceWeb, Hostland, SprintHost, AdminVPS. Ниже стоят партнёрские переходы; конкретный тариф подбирайте по проверенным требованиям архива.

  1. Timeweb — сверьте версии PHP, базу и доступ к файлам.
  2. МакХост — сопоставьте лимиты тарифа с размером проекта.
  3. SpaceWeb — уточните условия импорта и переноса у поддержки.
  4. Hostland — проверьте требования плагинов и доступные инструменты.
  5. SprintHost — запросите порядок тестовой проверки до смены DNS.
  6. AdminVPS — выясните, какой объём администрирования включён в услугу.

Список — партнёрская подборка, а не гарантия совместимости или независимый рейтинг тестов.

Какие части архива чаще всего забывают

В стандартной установке WordPress изображения живут в wp-content/uploads, но у проекта может быть подключено объектное хранилище. Проверьте, откуда реально загружаются картинки и PDF. Если файлы лежат на внешнем сервисе, для запуска важны его настройки и права доступа.

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

Приёмка по нескольким страницам

Где проверять Что сделать Что искать при ошибке
Старый URL статьи Открыть напрямую Правила постоянных ссылок
Карточка товара Сменить вариант и открыть фото Данные товара и файлы загрузок
Панель WordPress Загрузить тестовое изображение Права записи и лимиты PHP
Форма заявки Проверить тестовую доставку SMTP, настройки получателя, интеграцию с CRM
Корзина Оформить тестовый заказ Сессии, платёжный режим и вебхуки

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

Как восстановить магазин из вчерашней копии

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

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

Когда имеет смысл начинать заново

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

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

Проверьте копию перед распаковкой на сервере

Откройте архив локально или в закрытом рабочем каталоге. Проверьте wp-content/uploads, папки темы и плагинов, наличие SQL-дампа и дату копии. Если есть несколько архивов, начните с пары, снятой примерно в одно время. Для магазина сравните номер и дату последнего заказа с данными платёжного сервиса или CRM. Так можно определить, за какой промежуток нужна отдельная сверка.

Поднимите копию на новом хостинге

Создайте базу и отдельного пользователя, импортируйте SQL, разместите файлы и пропишите новое подключение к базе в wp-config.php. Сверьте префикс таблиц и версию PHP, необходимую плагинам. Если URL остаётся прежним, массовая замена адресов в базе обычно не нужна. Если адрес действительно меняется, используйте инструмент, который понимает сериализованные данные WordPress, и начните с пробного запуска. Документация WP-CLI.

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

Пройдите по сайту как клиент

Откройте статью по старому адресу, несколько товаров и страницу с PDF. Затем войдите в админку, проверьте загрузку картинки и отправку тестовой заявки. Если на сайте есть корзина, проверьте оформление и уведомления в тестовом режиме. Страница может выглядеть полностью восстановленной, пока первая форма не попытается отправить письмо со старого SMTP.

Что делать с изменениями после даты копии

Выгрузите из CRM или почты заказы и заявки, которых в архиве нет. Дозаполните их по согласованному порядку, сохраняя реальные статусы оплат и доставки. Храните первоначальный архив отдельно до окончания сверки. Руководство WordPress по переезду

Почему после импорта картинки открываются, а страницы дают 404

Если главная работает, проверьте правила постоянных ссылок и конфигурацию веб-сервера. Правила Apache из .htaccess напрямую не заменяют настройки Nginx. Если пропали только отдельные изображения, найдите их в архиве и сравните путь с тем, который запрашивает браузер. Не запускайте массовое исправление URL, пока не определили причину.

Проверьте целостность архива и происхождение файлов

Работайте с копией архива, оставив исходник неизменным. Если сервис передал контрольную сумму, сравните её до распаковки. Для нескольких архивов запишите размер и дату получения, чтобы отличать полную копию от частичной. SQL-дамп стоит открыть на тестовой базе и проверить структуру таблиц, префикс и контрольные записи, а не оценивать только успешное завершение импорта.

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

Проверьте особенности WooCommerce и динамических сайтов

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

Сайт с формами проверьте тестовой заявкой и убедитесь, что письмо приходит на нужный адрес. Если используется SMTP-плагин, его рабочие реквизиты нужно настроить отдельно. Не публикуйте сайт, пока не проверены доступы, базовая защита, обновления и регулярное создание резервных копий.

Оформите протокол приёмки

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

Чек-лист приёмки восстановленного WordPress

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

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

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

Отделите восстановление от обновления сайта

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

Удалите из открытого доступа временную копию и тестовые дампы, но сохраните их закрыто до завершения сверки данных. Обновите пароли, если копию передавали через общий или временный канал. Затем настройте уведомление о заполнении диска и ошибках резервного копирования. Сам факт включённой задачи не гарантирует пригодность архива: периодически проверяйте восстановление в изоляции.