Если сайт на WordPress перестал открываться после обновления, был взломан или начал выдавать ошибки, резервная копия часто остается самым быстрым способом вернуть его в рабочее состояние. Но восстановление зависит от того, что именно у вас сохранено: только файлы, только база данных или полный бэкап с обоими компонентами. Ошибка на этом этапе обычно стоит времени и данных, поэтому сначала нужно понять, какой у вас тип копии и что именно сломалось.
Самый безопасный сценарий — восстановить сайт на отдельной копии или в тестовом окружении, проверить результат и только потом заменять рабочую версию. Если такой возможности нет, делайте восстановление аккуратно и заранее сохраните текущие файлы и базу: даже «битый» сайт может содержать свежие комментарии, заказы, формы или правки, которые не попали в бэкап.
Какие бывают резервные копии WordPress
В WordPress резервные копии обычно делятся на три типа, и от этого зависит способ восстановления.
- Полная копия — содержит файлы сайта и дамп базы данных. Это лучший вариант: после восстановления сайт возвращается почти в то же состояние, что и на момент создания бэкапа.
- Только файлы — обычно это папки WordPress, темы, плагины, загрузки и иногда конфигурация сервера. Такой бэкап не вернет записи, страницы, настройки и пользователей без базы данных.
- Только база данных — подходит, если нужно вернуть контент, настройки и пользователей, но не восстановит отсутствующие файлы темы, плагинов и медиа, если их нет на сервере.
На практике это важно: если после неудачного обновления сломалась тема, иногда достаточно вернуть только файлы. Если сайт взломали и в базе появились вредоносные вставки, придется восстанавливать и базу, и файлы, а затем отдельно проверять безопасность.
Что проверить до восстановления
Перед тем как откатывать сайт, стоит понять, не потеряете ли вы свежие данные. Это особенно важно для интернет-магазинов, сайтов с формами заявок и активных блогов.
- Сохраните текущую версию сайта: скачайте файлы и экспортируйте базу данных, даже если сайт работает нестабильно.
- Проверьте дату бэкапа: чем старше копия, тем выше риск потерять новые записи, заказы, комментарии и настройки.
- Уточните, что входит в архив: иногда в нем нет папки
uploadsили базы данных. - Если сайт взломан, не восстанавливайте зараженную копию поверх текущей без проверки — можно вернуть вредоносный код вместе с сайтом.
Если у вас есть доступ к панели хостинга, сначала создайте отдельную папку или поддомен для тестового восстановления. Это не обязательный шаг, но он сильно снижает риск испортить рабочий сайт окончательно.
Как восстановить WordPress из полной резервной копии
Полная копия обычно состоит из двух частей: файлов сайта и базы данных. Восстанавливать их лучше в таком порядке: сначала файлы, потом база. Но если хостинг или плагин резервного копирования предлагает свой порядок, следуйте его инструкции — некоторые решения автоматически подставляют нужные параметры подключения к базе.
1. Верните файлы сайта
Если архив с файлами у вас на компьютере, загрузите его через файловый менеджер хостинга или по FTP/SFTP. Обычно нужно заменить содержимое корня сайта, где лежат папки wp-admin, wp-content и wp-includes.
Если вы восстанавливаете сайт после сбоя, не удаляйте текущие файлы вслепую. Сначала переименуйте старую папку сайта или сохраните ее как резервную копию. Так вы сможете откатиться назад, если в архиве не окажется нужных данных или если восстановление пойдет не так.
Особое внимание уделите папке wp-content: именно там лежат темы, плагины и загруженные изображения. Если восстановить только ядро WordPress, сайт может запуститься, но внешний вид и часть функций будут сломаны.
2. Импортируйте базу данных
База данных восстанавливается через phpMyAdmin, Adminer или инструмент, который дает хостинг. Обычно нужен файл .sql или архив, который сначала распаковывается в SQL-дамп.
Перед импортом проверьте, в ту ли базу вы загружаете данные. Ошибка здесь опасна: можно перезаписать чужой проект или смешать данные двух сайтов. Если не уверены, создайте новую базу и укажите ее в wp-config.php перед импортом.
После импорта проверьте, совпадают ли префикс таблиц и параметры подключения в wp-config.php. Если в бэкапе таблицы начинаются, например, с wp_, а в конфиге указан другой префикс, WordPress может не увидеть данные.
3. Проверьте файл wp-config.php
После восстановления базы откройте wp-config.php и убедитесь, что там указаны правильные имя базы, пользователь, пароль и хост. Если сайт переносили между серверами или восстанавливали на новом аккаунте хостинга, эти значения часто меняются.
Также проверьте, не остались ли в конфиге старые значения домена, если вы восстанавливали сайт на временный адрес. Для обычного восстановления это не требуется, но при переносе или тестовом запуске может быть критично.
Если бэкап сделан плагином
Многие плагины резервного копирования умеют восстанавливать сайт одной кнопкой, но логика у них разная. Одни разворачивают архив прямо из админки WordPress, другие требуют восстановление через отдельный скрипт или панель хостинга.
Общий принцип такой: если плагин сам создал архив, лучше использовать его же для восстановления. Это снижает риск несовместимости формата и упрощает возврат файлов, базы и настроек. Перед запуском восстановления проверьте, не требует ли плагин временного отключения кэша, режима обслуживания или ручной замены файлов.
Если админка WordPress не открывается, а плагин восстанавливает сайт только из панели управления, этот способ не поможет. Тогда придется работать через хостинг, FTP/SFTP и phpMyAdmin.
Как восстановить сайт после взлома
При взломе простого отката из старого бэкапа может быть недостаточно. Если восстановить зараженную копию, проблема вернется сразу после запуска сайта.
В таком случае действуйте в два этапа: сначала верните чистую резервную копию, затем проверьте, не осталось ли следов взлома в текущих файлах и базе. Обычно имеет смысл:
- заменить все файлы WordPress на чистые из резервной копии или свежего дистрибутива WordPress;
- проверить папку
wp-contentна подозрительные PHP-файлы; - сменить пароли администратора, FTP/SFTP, базы данных и панели хостинга;
- обновить ключи безопасности в
wp-config.php; - проверить пользователей с правами администратора и удалить лишние учетные записи.
Если заражение было серьезным и вы не уверены в чистоте бэкапа, безопаснее восстановить только контент из базы данных, а файлы темы и плагинов взять из свежих официальных источников. Это дольше, но надежнее, чем тащить на сайт старый вредоносный код.
Как проверить, что восстановление прошло успешно
После восстановления не ограничивайтесь открытием главной страницы. Часто сайт выглядит рабочим, но внутри остаются ошибки, которые проявляются только на отдельных разделах.
- Откройте главную страницу и несколько внутренних страниц.
- Проверьте вход в админку WordPress.
- Посмотрите, отображаются ли изображения из медиатеки.
- Откройте формы, комментарии и другие интерактивные элементы.
- Если сайт использует постоянные ссылки, зайдите в Настройки → Постоянные ссылки и просто сохраните их без изменений — это часто помогает восстановить правила маршрутизации после переноса или отката.
Если после восстановления появились ошибки 404 на внутренних страницах, проблема нередко связана не с бэкапом, а с правилами .htaccess или настройками ЧПУ. На Apache это решается пересохранением постоянных ссылок, а на Nginx может потребоваться проверка конфигурации сервера.
Когда восстановление не решает проблему полностью
Бэкап возвращает сайт в прошлое состояние, но не исправляет причину сбоя. Если ошибка возникла из-за несовместимого плагина, устаревшей версии PHP, нехватки памяти или поврежденной темы, после восстановления проблема может повториться.
Поэтому после успешного отката стоит сразу проверить, что именно привело к сбою: последнее обновление плагина, смена версии PHP, ручные правки в теме или подозрительная активность в админке. Иначе через день или неделю вы снова окажетесь в той же точке, только уже без свежего бэкапа.
Если резервные копии у вас еще не настроены, имеет смысл сразу организовать регулярное создание полных бэкапов и хранить их не только на хостинге, но и вне сервера. Для сайта на WordPress это базовая страховка: восстановление всегда проще, когда копия уже есть и вы знаете, где она лежит.