Резервная копия WordPress: как сохранить и восстановить сайт

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

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

Что должно входить в копию

• SQL-экспорт базы со всеми таблицами сайта, включая таблицы плагинов.
• Каталог wp-content с загрузками, темами, плагинами и mu-plugins, если они используются.
• Конфигурация wp-config.php и файлы в корне, нужные для работы, включая скрытые файлы.
• Отдельная запись о версиях PHP и WordPress, заданиях cron, настройках сервера и внешнем хранилище файлов.

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

Как сделать копию через панель хостинга

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

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

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

Пример для сайта с SSH и WP-CLI

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

wp db export /private-backups/site-before-update.sql

Команда экспортирует базу, но не изображения, темы или конфигурацию. Их нужно сохранить отдельно. Проверь успешное завершение и ненулевой размер SQL-файла. WP-CLI требует доступных клиентских утилит MySQL; при их отсутствии используй панель или помощь администратора.

Не оставляй SQL и архивы в public_html, uploads или другом каталоге, который открывается по HTTP. В базе могут быть персональные данные и служебные значения. Для удалённого хранения используй закрытый доступ; ключи от хранилища не должны лежать рядом с публичными исходниками.

Где хранить и как часто копировать

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

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

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

Как проверить восстановление

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

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

wp db import /private-backups/site-before-update.sql

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

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

Если восстанавливаешь рабочий сайт

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

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

Восстановление копии на новом сервере близко к переезду: порядок действий описан в инструкцией по переносу WordPress.

Документация

Резервное копирование WordPress · wp db export · wp db import.