Как восстановить сайт WordPress из резервной копии на хостинге

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

Дата публикации: 12 ноября 2026 года.

Что проверить до восстановления WordPress?

Начните с причины сбоя. Если сайт показывает ошибку 503, сервер получил запрос, но сейчас не может его обработать. Причиной бывает перегрузка или работы на сервере; сама по себе такая ошибка не означает, что файлы сайта пропали (источник: «Ошибка 503 на сайте: что значит и что проверить»). Откройте панель хостинга и посмотрите сообщения о работах и ограничениях. Если проблема на стороне сервера, замена файлов из копии не устранит её.

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

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

Найдите пару файлов и базы за близкий момент времени. Файлы содержат WordPress, плагины, тему и загруженные изображения. База хранит тексты страниц, настройки, учётные записи и заказы. В панели хостинга копии этих частей могут лежать в разных разделах, поэтому проверьте дату и состав каждой. Отдельно запишите, какой каталог относится к рабочему домену и какая база указана в файле wp-config.php.

Как вернуть файлы и базу данных в правильном порядке?

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

1. В панели хостинга выберите копию файлов и проверьте каталог назначения. Если панель предлагает восстановить весь аккаунт, сначала уточните у поддержки, затронет ли операция почту или другие сайты в этом аккаунте.
2. Верните файлы в каталог рабочего сайта. Проверьте, что в нём появились папки wp-admin, wp-content и wp-includes. Не распаковывайте архив во вложенную папку, если сайт прежде работал из корня каталога.
3. Импортируйте базу из копии через инструмент хостинга. Перед подтверждением ещё раз сверьте имя базы: импорт поверх другой базы повредит сайт, который с ней работает. Не удаляйте текущий экспорт, пока проверка не завершена.
4. Откройте wp-config.php и сравните имя базы, пользователя и пароль с данными панели хостинга. Если базу восстановили под новым именем, обновите подключение к ней в этом файле.

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

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

Как проверить страницы, заявки и заказы после запуска?

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

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

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

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

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

Какие ошибки чаще мешают восстановлению?

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

Первое действие сейчас: откройте панель хостинга и найдите даты последних копий файлов и базы WordPress. Запишите обе даты, прежде чем нажимать «Восстановить».