Резервные копии WordPress: практический пример

Если сервер с WordPress выйдет из строя, одного архива каталога сайта недостаточно: записи, настройки и заказы находятся в базе данных. Ниже — практическая схема для WordPress 6.x на Linux с WP-CLI 2.x и MySQL или MariaDB. За 20–30 минут вы настроите локальную копию файлов и базы, а затем сможете перенести архив на другой сервер.

Что именно нужно сохранить

Резервная копия WordPress состоит из двух частей. Первая — база данных: посты, страницы, пользователи, настройки, комментарии и данные плагинов. Вторая — файлы: ядро, темы, плагины, изображения из wp-content/uploads и конфигурация.

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

Хорошая копия — это не файл, который удалось создать, а архив, из которого вы проверенно восстановили сайт.

Сноска. Снимок — копия состояния данных на определённый момент времени. В этой схеме создаётся не снимок диска, а логическая копия базы и файлов сайта.

Три подхода и их цена

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

Для практического примера выберем WP-CLI. Он не заменяет внешнее хранилище, но даёт понятный процесс: экспорт базы, упаковка файлов, проверка архива и удаление старых копий.

Подготовка перед первым запуском

• WordPress 6.x установлен на Linux-сервере.
• Есть SSH-доступ к пользователю, который владеет файлами сайта или может читать их.
• Установлен WP-CLI 2.x. Версию можно проверить командой wp --info.
• Известен путь к сайту, например /var/www/example. Замените его на свой.
• На диске есть свободное место минимум размером с текущий сайт плюс экспорт базы и запас на несколько копий.
• Есть отдельное хранилище: другой сервер, объектное хранилище или компьютер администратора.

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

Практический сценарий через WP-CLI

Шаг 1. Создайте каталог для временной копии

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

cd /var/www/example
mkdir -p "$HOME/wordpress-backups"
wp core is-installed

Команда wp core is-installed должна завершиться без сообщения об ошибке. Если WP-CLI не видит установку, проверьте путь и наличие файла wp-config.php.

Шаг 2. Экспортируйте базу данных

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

backup_date=$(date +%F-%H%M%S)
backup_dir="$HOME/wordpress-backups/$backup_date"
mkdir -p "$backup_dir"
wp db export "$backup_dir/database.sql"

Проверка — в каталоге должна появиться непустая строка database.sql. Размер файла зависит от проекта; нулевой файл или ошибка подключения означают, что копию нельзя считать готовой.

Шаг 3. Упакуйте файлы сайта

В архив попадут конфигурация, темы, плагины и загрузки. Каталог с временными резервными копиями находится вне /var/www/example, поэтому сам в архив не попадёт.

tar -czf "$backup_dir/files.tar.gz" \
  --exclude="./wp-content/cache" \
  --exclude="./wp-content/upgrade" \
  -C /var/www/example .

Исключение кеша уменьшает размер архива: кеш можно создать заново. Не исключайте wp-content/uploads, wp-content/themes и wp-content/plugins, если рассчитываете восстановить сайт целиком.

Проверка — команда должна завершиться без ошибки, а размер files.tar.gz должен быть больше нуля.

Шаг 4. Проверьте содержимое и целостность

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

test -s "$backup_dir/database.sql" && echo "database: OK"
test -s "$backup_dir/files.tar.gz" && echo "files: OK"
gzip -t "$backup_dir/files.tar.gz" && echo "archive: OK"
tar -tzf "$backup_dir/files.tar.gz" | head -n 20

В выводе должны появиться три строки со статусом OK, а затем пути вроде ./wp-config.php и ./wp-content/. Если в архиве нет загрузок или конфигурации, остановитесь и исправьте команду до отправки копии наружу.

Шаг 5. Удалите старые локальные копии

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

find "$HOME/wordpress-backups" \
  -mindepth 1 -maxdepth 1 -type d -mtime +14 \
  -exec rm -rf -- {} \;

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

Как сделать копию регулярной

Ручной запуск подходит для проверки, но не для постоянной защиты. В production-окружении вынесите команды в отдельный исполняемый скрипт и запланируйте его через cron. В скрипте должны быть абсолютные пути, проверка ошибок и отправка готового архива во внешнее хранилище.

Простейший вариант — запускать процесс раз в сутки ночью. Точное расписание зависит от нагрузки и характера сайта: интернет-магазину с заказами нельзя бездумно выбирать момент пиковых операций. Cron только запускает процесс; он не подтверждает, что архив действительно отправился на другой сервер.

После каждой автоматической копии проверяйте:

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

Что ломается чаще всего

Недостаточно места

Ошибка вроде No space left on device появляется во время экспорта или упаковки. Удалите старые локальные архивы только после проверки, что внешняя копия существует, и добавьте контроль свободного места.

Нет прав на чтение файлов

Сообщение Permission denied означает, что пользователь запускает команду без доступа к части WordPress. Не меняйте права рекурсивно наугад: выясните владельца файлов и запускайте резервное копирование от подходящего системного пользователя.

В архиве нет базы или загрузок

Так бывает, если экспорт запускался не из каталога нужного сайта или в команду tar передали неверный путь. Проверяйте wp core is-installed, затем просматривайте список файлов через tar -tzf.

Копия есть, но восстановить её нельзя

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

Когда выбирать другой подход

Плагин удобнее, если у вас нет SSH и сайт небольшой. Копия хостинга полезнее, когда требуется вернуть не только WordPress, но и настройки сервера. WP-CLI предпочтителен, когда сайт обслуживается регулярно, нужно видеть каждый этап и отправлять архив в независимое хранилище.

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

Что делать дальше

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