Резервная копия WordPress нужна не для галочки в панели хостинга. Её задача — вернуть рабочий сайт после ошибки обновления, повреждения базы, неудачной доработки, сбоя сервера или инцидента безопасности.
Самая частая проблема — копии вроде бы создаются, но никто не знает, что именно в них входит и можно ли из них восстановиться. Надёжная схема начинается с понимания двух частей WordPress: файлов и базы данных.
Что именно нужно копировать
Официальная документация WordPress разделяет резервное копирование на две части: файлы сайта и базу данных. Для полного восстановления типичного WordPress-проекта нужны обе.
Файлы WordPress
В файловой части находятся ядро, плагины, темы, загрузки, wp-config.php, серверные конфигурационные файлы и кастомный код. На практике особенно важны wp-content/uploads, активная тема, custom plugins/mu-plugins и конфигурация проекта.
База данных
В базе хранятся записи, страницы, настройки, пользователи, метаданные, многие настройки плагинов, WooCommerce-заказы и другой динамический контент. Простое скачивание каталога сайта не делает резервную копию MySQL/MariaDB.
Почему одной копии недостаточно
Если единственный бэкап хранится на том же VPS или хостинге, что и production, он может исчезнуть вместе с сервером. Если все копии синхронно перезаписываются, ошибка или заражённые файлы могут попасть во все актуальные версии.
Практическая схема обычно включает несколько поколений копий и хотя бы одно хранилище вне production. Это может быть объектное хранилище, отдельный сервер или облачный диск — важно не название сервиса, а независимость от основного сайта.
Как определить частоту бэкапов
Расписание зависит от того, сколько данных сайт может позволить себе потерять. Для статичного корпоративного сайта изменения могут происходить редко. Для WooCommerce-магазина новые заказы появляются постоянно, поэтому недельная копия базы может означать потерю важных данных.
| Тип сайта | Что меняется | Что учитывать |
|---|---|---|
| Сайт услуг | Контент и заявки | Частота публикаций и способ хранения заявок |
| Блог | Записи, комментарии, медиа | Частота публикаций и редакторская работа |
| WooCommerce | Заказы, клиенты, остатки, настройки | Нужны более частые копии базы и аккуратный restore |
| Личный кабинет | Пользовательские данные | Оценить допустимую потерю последних изменений |
Вместо универсального «раз в сутки» полезнее определить два параметра: сколько последних данных допустимо потерять и как быстро сайт должен быть восстановлен.
Автоматический бэкап лучше ручного, но его нужно контролировать
Автоматизация снижает риск забыть о копии перед обновлением или после очередной недели работы. Но задача не заканчивается успешной надписью «backup completed».
- проверяйте, что задача реально запускается по расписанию;
- следите за ошибками загрузки во внешнее хранилище;
- контролируйте свободное место;
- храните несколько поколений, а не только последнюю копию;
- периодически скачивайте или восстанавливайте тестовый набор.
Бэкап перед обновлением и доработкой
Перед обновлением ядра, крупного плагина, темы или PHP разумно создать свежую точку восстановления. То же относится к миграциям, массовому импорту товаров, изменению структуры базы и серьёзной доработке checkout.
Для сложного production-сайта лучше сначала проверить изменение на staging. Резервная копия — страховка, а не замена тестированию.
Что хранить вместе с копией
Чем сложнее проект, тем полезнее хранить метаданные резервного набора: дату, окружение, версию PHP, домен, размер файлов, дамп базы и информацию о том, как именно выполнялось копирование.
Для ручного серверного процесса можно сохранять контрольные суммы архивов. Они помогают убедиться, что файл не повредился при транспортировке.
Пример базовой серверной схемы
Ниже не готовый скрипт для любого хостинга, а упрощённая логика. Имена базы, пути и секреты должны приходить из защищённой конфигурации, а не быть зашиты в публичный код.
# 1. создать дамп базы
mysqldump --single-transaction DB_NAME | gzip > db.sql.gz
# 2. заархивировать нужные файлы
tar -czf files.tar.gz /path/to/wordpress
# 3. вычислить контрольные суммы
sha256sum db.sql.gz files.tar.gzПароль базы не следует помещать прямо в команду, если он попадёт в shell history или логи. Конкретный безопасный способ зависит от инфраструктуры сервера.
Восстановление важнее создания копии
Копия считается проверенной только после теста восстановления. Идеально — периодически разворачивать её на отдельном staging-домене или временном окружении и проходить основные проверки.
- развернуть файлы;
- создать чистую базу;
- импортировать дамп;
- проверить параметры подключения в
wp-config.php; - если домен менялся — выполнить корректную замену URL с учётом сериализованных данных;
- очистить кэши;
- проверить фронтенд и админку;
- для WooCommerce сделать тестовый заказ без реальной оплаты или в тестовом режиме;
- проверить формы, cron и интеграции.
Почему нельзя делать обычный SQL search/replace для домена
В WordPress встречаются сериализованные структуры. Простая замена текста непосредственно в SQL-дампе может нарушить длины сериализованных значений и повредить настройки.
Для миграций удобнее использовать инструменты, которые понимают сериализацию, например соответствующие команды WP-CLI или проверенные миграционные инструменты.
WooCommerce: восстановление требует особой осторожности
У магазина база постоянно меняется. Если восстановить вчерашний дамп поверх сегодняшнего production, можно потерять новые заказы и изменения клиентов. Перед restore нужно зафиксировать текущее состояние и определить, какие данные необходимо сохранить отдельно.
Поэтому для магазина аварийный план лучше подготовить заранее, а не проектировать его в момент сбоя.
Безопасность резервных копий
Бэкап содержит те же чувствительные данные, что и production. Дамп базы может включать персональные данные, настройки интеграций и служебную информацию. Копии нужно защищать от публичного доступа.
- не храните архив в публичном каталоге сайта;
- не используйте предсказуемые URL для скачивания;
- ограничивайте доступ к облачному хранилищу;
- используйте шифрование там, где оно требуется архитектурой и политикой данных;
- удаляйте старые копии по понятной retention-политике;
- не отправляйте дампы базы через открытые чаты.
Бэкапы — один из уровней общей безопасности WordPress, но они не заменяют обновления и контроль доступа.
Плагин, хостинг или серверный скрипт
У каждого подхода есть своё место. Плагин удобен на обычном хостинге и даёт понятный интерфейс. Бэкап хостинга полезен как дополнительный уровень. На VPS можно настроить серверный процесс с отдельным хранилищем и мониторингом.
| Подход | Плюс | Что проверить |
|---|---|---|
| Плагин WordPress | Простая настройка | Ограничения хостинга, размер архива, внешнее хранилище |
| Backup хостинга | Не зависит от WordPress-плагина | Retention, возможность самостоятельного restore, что именно входит |
| Серверный backup | Максимальный контроль | Скрипты, права, мониторинг, ротация, защита секретов |
Минимальный чек-лист рабочей схемы
- копируются и файлы, и база данных;
- процесс запускается автоматически;
- есть несколько поколений копий;
- хотя бы одна копия хранится вне production;
- ошибка backup-задачи не остаётся незамеченной;
- перед крупными изменениями создаётся свежая точка восстановления;
- копии недоступны из публичного веб-каталога;
- известен пошаговый restore-процесс;
- восстановление периодически проверяется на тестовом окружении.
Когда стоит настроить сопровождение
Если сайт приносит заявки, принимает заказы или содержит критичные интеграции, резервное копирование лучше включить в общий процесс обслуживания: обновления, мониторинг, проверку форм, серверные логи и контроль свободного места.
Подробнее о таком формате — техническая поддержка WordPress. Для разовой настройки или исправления существующей схемы можно заказать доработку WordPress.
Частые вопросы
Достаточно ли скачать папку wp-content?
Нет для полного восстановления типичного сайта. wp-content содержит важные файлы, но отдельно нужна база данных и часть конфигурации.
Как часто делать резервные копии?
Частота зависит от активности сайта и допустимой потери данных. Чем чаще появляются заказы, пользователи или новый контент, тем меньше должен быть интервал между копиями.
Можно ли хранить бэкап на том же сервере?
Как один из уровней — да, но единственную копию лучше не оставлять рядом с production. Независимое хранилище защищает от части серверных сбоев и ошибок.
Нужно ли проверять восстановление, если backup-задача пишет SUCCESS?
Да. Успешное создание архива ещё не гарантирует, что внутри полный набор данных и что restore-процесс работает.
Что важнее копировать для WooCommerce — файлы или базу?
Нужны обе части, но новые заказы и клиентские данные находятся в базе, поэтому её частота и аккуратность восстановления особенно важны.
Вывод
Надёжный бэкап WordPress — это не один ZIP-файл. Это повторяемый процесс: файлы плюс база, расписание, независимое хранение, ротация, контроль ошибок и периодический тест восстановления.
Если текущая схема непонятна или сайт никогда не восстанавливался из копии, можно прислать данные об инфраструктуре через контакты A.S Groups и отдельно оценить настройку backup/restore.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.