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

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

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

Сначала проверьте, что именно нужно восстановить

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

Обычно встречаются три сценария:

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

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

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

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

Совместимость версии WordPress, PHP и плагинов

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

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

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

Что входит в бэкап

Резервная копия может содержать:

• только базу данных;
• только файлы сайта;
• и файлы, и базу данных вместе.

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

Есть ли свежие данные, которые нельзя потерять

Перед откатом проверьте:

• новые заказы в WooCommerce;
• новые заявки из форм;
• комментарии и регистрации пользователей;
• изменения в контенте после даты бэкапа.

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

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

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

Чаще всего плагины резервного копирования умеют:

• хранить копии в облаке или на сервере;
• восстанавливать сайт из админки WordPress;
• отдельно возвращать файлы, базу данных или всё сразу.

Общий порядок такой:

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

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

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

Восстановление через хостинг обычно надёжнее, чем кажется

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

Что обычно нужно сделать:

1. Зайти в панель хостинга.
2. Открыть раздел резервных копий или backup.
3. Выбрать дату копии, которая вам нужна.
4. Указать, что восстанавливать: файлы, базу данных или всё целиком.
5. Запустить восстановление и дождаться уведомления о завершении.

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

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

Если бэкап есть только в виде файлов и дампа базы

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

Порядок такой:

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

Если база импортируется в новую БД, а домен или путь к сайту менялся, может понадобиться обновить значения siteurl и home в таблице wp_options. Делайте это только если понимаете, что именно меняете: неверное значение может снова увести сайт в ошибку или циклический редирект.

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

Как не потерять свежие данные при откате

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

Что стоит сделать до отката:

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

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

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

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

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

• Главная и внутренние страницы — нет ли 404, битых блоков и пустых секций.
• Вход в админку — работает ли авторизация, не слетели ли права пользователей.
• Постоянные ссылки — если страницы открываются с ошибкой, зайдите в Настройки → Постоянные ссылки и просто сохраните их заново.
• Формы — отправляется ли письмо, создаётся ли заявка, не сломалась ли интеграция с почтой.
• Медиафайлы — открываются ли изображения и документы.
• Кеш — очистите кеш плагина, сервера и CDN, если они используются.

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

Когда лучше не восстанавливать всё целиком

Полный откат — не всегда лучший вариант. Иногда достаточно вернуть только то, что сломалось.

Например:

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

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

Если резервной копии нет

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

Если бэкапа нет совсем, сначала проверьте:

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

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

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