Бэкап WordPress: что сохранить и как проверить копию

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

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

Как проверен материал. Утверждения сверены с официальной документацией. Описанная процедура создания копии и восстановления не воспроизводилась ни на реальном сайте, ни в изолированном окружении.

1. Разделите файлы и базу данных

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

Файлы включают код WordPress, темы, плагины, изображения и документы. Сохраните также конфигурацию wp-config.php, скрытые файлы вроде .htaccess, если сайт его использует, и другие необходимые файлы. В руководстве по копированию файлов отдельно упомянуты wp-content и wp-config.php.

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

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

2. Соберите один набор для восстановления

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

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

Запишите рядом с копией:

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

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

Перед обновлением PHP сохраните отдельный набор до начала работ. Он станет точкой возврата. Храните его отдельно от новых копий, чтобы не перепутать версии.

3. Выберите частоту по допустимой потере данных

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

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

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

4. Храните копию отдельно от сайта

WordPress рекомендует хранить резервные копии в разных местах. Так при потере доступа к основному аккаунту у вас останется другой путь к нужному набору.

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

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

После переноса проверьте, что нужные файлы доступны, а архив читается. Это проверяет сам файл копии, но ещё не подтверждает восстановление сайта.

5. Проверьте восстановление на изолированной копии

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

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

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

Восстанавливайте копию по инструкции выбранного инструмента или хостинга. Здесь нет готовой команды импорта. Например, WP-CLI выполняет SQL в базе, указанной в конфигурации. До запуска точно установите целевую базу: ошибка в выборе изменит данные не того сайта.

После восстановления проверьте именно тестовую копию:

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

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

Ошибки, которые мешают восстановлению

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

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

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

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

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

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