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

Если сайт WordPress сломался после обновления, был взломан или вы случайно удалили важные данные, резервная копия часто оказывается самым быстрым способом вернуть его в рабочее состояние. Но восстановление — это не просто «залить бэкап обратно». Сначала нужно понять, что именно вы восстанавливаете: только файлы, только базу данных или весь сайт целиком. От этого зависит и порядок действий, и риск потерять свежие изменения.

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

Что именно нужно восстановить: сайт целиком или только часть

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

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

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

Перед восстановлением: что проверить, чтобы не потерять свежие данные

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

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

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

Самый простой способ: восстановление через плагин резервного копирования

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

Алгоритм обычно такой:

1. Откройте настройки плагина резервного копирования в админке WordPress.
2. Найдите список доступных резервных копий.
3. Выберите нужную дату и запустите восстановление файлов и базы данных.
4. Дождитесь завершения процесса и не закрывайте вкладку раньше времени.

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

Если вы только выбираете инструмент для будущих бэкапов, смотрите не только на создание копии, но и на удобство восстановления. Для части сайтов это важнее. На практике полезны плагины, которые умеют хранить копии вне сервера и быстро разворачивать их без ручной работы. Подборку таких решений можно смотреть в каталоге плагинов WPShop: https://wpshop.ru/plugins.

Когда плагин — лучший вариант

Плагин особенно удобен, если:

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

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

Восстановление через панель хостинга

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

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

Этот способ удобен тем, что не зависит от состояния WordPress. Но у него есть ограничения:

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

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

Ручное восстановление: когда без него не обойтись

Ручной способ нужен, если бэкап хранится в виде архива и SQL-файла, а автоматического восстановления нет. Это рабочий вариант, но он требует аккуратности. Если сомневаетесь, лучше сначала восстановить копию на тестовом домене или поддомене.

В общих чертах процесс такой:

1. Скачайте архив с файлами сайта и дамп базы данных.
2. Через FTP/SFTP или файловый менеджер хостинга загрузите файлы сайта в нужную папку, обычно это корень сайта.
3. Если нужно, удалите старые повреждённые файлы перед загрузкой новых, но только после того, как у вас есть свежая копия текущего состояния.
4. Откройте phpMyAdmin или другой инструмент управления базой данных и импортируйте SQL-файл в нужную базу.
5. Проверьте файл `wp-config.php`: имя базы, пользователь, пароль и хост должны соответствовать восстановленной базе.

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

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

Как проверить, что сайт восстановился правильно

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

Проверяйте сайт по порядку:

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

Отдельно проверьте, совпадают ли версии WordPress, темы и плагинов с теми, что были на момент создания бэкапа. Иногда после восстановления старой копии сайт просит обновить базу данных или показывает уведомления о несовместимости. Это нормально, если вы откатили сайт на более раннюю версию, но такие сообщения нельзя игнорировать.

Типичные проблемы после восстановления

Самая частая ситуация — сайт открылся, но часть элементов выглядит иначе. Обычно это связано не с самим бэкапом, а с кешем, CDN, разницей версий плагинов или темой, которая обновлялась отдельно от базы данных.

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

После восстановления из старого бэкапа иногда нужно заново сохранить постоянные ссылки в разделе «Настройки → Постоянные ссылки». Это безопасное действие, которое обновляет правила маршрутизации и помогает убрать 404 на страницах.

Какой способ выбрать в реальной ситуации

Ситуация	Что делать
Админка WordPress открывается, бэкап делал плагин	Восстанавливать через тот же плагин
WordPress не открывается, но есть панель хостинга	Использовать резервные копии хостинга
Есть только архив и SQL-файл	Восстанавливать вручную через FTP/SFTP и phpMyAdmin
Сайт с заказами или активными данными	Сначала сохранить свежие данные, потом откатывать копию

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

Главное правило простое: не восстанавливайте сайт вслепую. Сначала определите, какая копия нужна, потом выберите способ восстановления, а после отката обязательно проверьте контент, дизайн и рабочие сценарии сайта. Тогда резервная копия действительно поможет вернуть сайт, а не создаст новую проблему.