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

Резервная копия WordPress — комплект связанных частей, а не один zip. База содержит записи и настройки, uploads — пользовательские файлы, wp-config.php — реквизиты, а список версий помогает воспроизвести код. Проверенным backup становится только после восстановления.

Определите допустимую потерю данных

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

Создайте временный каталог вне web root

Следующие команды создают закрытый каталог, доступный только владельцу, и записывают время UTC для связи файлов в один комплект:

sudo install -d -o deploy -g deploy -m 0700 /home/deploy/backups/wordpress-manual
date -u +%FT%TZ | sudo -u deploy tee /home/deploy/backups/wordpress-manual/created-at.txt

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

Экспортируйте базу и изменяемые файлы

На сайте с активной записью включите короткое обслуживание или используйте согласованный механизм приложения. Затем создайте dump и архив uploads/config:

mariadb-dump -u wp_app -p --single-transaction wordpress \
  > /home/deploy/backups/wordpress-manual/database.sql
tar -czf /home/deploy/backups/wordpress-manual/files.tar.gz \
  -C /srv/www/example.com shared \
  -C /srv/www/example.com/current wp-config.php wp-content/themes wp-content/plugins

Пароль вводится интерактивно. --single-transaction согласует таблицы InnoDB, а tar сохраняет uploads, конфигурацию, темы и плагины. Проверьте, что указанные пути соответствуют реальной структуре; не считайте кеш обязательными данными.

Добавьте версии и суммы:

wp --path=/srv/www/example.com/current core version > /home/deploy/backups/wordpress-manual/versions.txt
wp --path=/srv/www/example.com/current plugin list --format=csv >> /home/deploy/backups/wordpress-manual/versions.txt
cd /home/deploy/backups/wordpress-manual
sha256sum database.sql files.tar.gz versions.txt created-at.txt > SHA256SUMS

После этого верните сайт из обслуживания и выполните smoke-проверку. Файл сумм не шифрует данные; архив по-прежнему содержит пароль базы.

Скачайте комплект на локальный компьютер

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

scp -r deploy@example.com:/home/deploy/backups/wordpress-manual ./wordpress-backup-2026-08-25
cd ./wordpress-backup-2026-08-25
sha256sum --check SHA256SUMS

Все строки должны завершиться OK. Затем ограничьте локальный доступ, сделайте вторую копию на другом носителе и удалите временный серверный комплект только после теста восстановления.

Восстановите в отдельное окружение

Подготовьте чистую тестовую базу и каталог, распакуйте файлы, исправьте реквизиты staging и импортируйте SQL. Не направляйте домен production на тест.

После импорта проверьте число таблиц, главную, несколько статей, изображения, вход, cron и журнал PHP. Если URL меняется, используйте WP-CLI search-replace с dry-run и поддержкой сериализованных данных.

Измерьте время от начала до работающего сайта. Запишите недостающие пакеты, ручные секреты и команды — они являются частью восстановления. Если тест не завершён, комплект остаётся лишь непроверенной копией.

Архивы не заменяют процедуру staging-обновления и должны учитываться в мониторинге WordPress.

Источники

• WordPress backups
• WordPress database backup
• MariaDB dump documentation
• GNU coreutils sha256sum