Стратегия 3-2-1

Правило резервного копирования: 3 копии данных, на 2 разных носителях, и 1 копия вне сайта (облако, другой сервер).

⚠️ Бэкап на том же сервере, что и сайт — не считается надёжным. При потере сервера потеряете и бэкап.

UpdraftPlus: настройка

Установите плагин UpdraftPlus, перейдите в Настройки → UpdraftPlus:

Настройка	Рекомендуемое значение
Расписание файлов	Ежедневно
Хранить копий	7
Расписание БД	Каждые 4 часа
Хранилище	Google Drive / S3 / Dropbox

Ручной бэкап через CLI

#!/bin/bash
DATE=$(date +%Y%m%d_%H%M)
SITE_DIR=/var/www/mysite
BACKUP_DIR=/backups/wordpress

# Бэкап базы данных
mysqldump -u wpuser -p wppassword wpdb > $BACKUP_DIR/db_$DATE.sql

# Бэкап файлов
tar -czf $BACKUP_DIR/files_$DATE.tar.gz $SITE_DIR/wp-content/

# Удаление старых бэкапов (старше 30 дней)
find $BACKUP_DIR -mtime +30 -delete

Добавление в cron

crontab -e
# Ежедневно в 3:00
0 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

💡 Проверяйте бэкапы раз в месяц — разворачивайте копию на тестовом сервере и убеждайтесь что всё работает.

Разбор типичных ошибок бэкапа и восстановления

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

Текст ошибки или симптом	Причина	Что делать
Error establishing a database connection после восстановления дампа	В wp-config.php остались старые DB_NAME, DB_USER и DB_HOST от исходного сервера	Прописать константы новой базы перед первым запуском сайта
mysqldump: Got error: 1044 access denied when using LOCK TABLES	У пользователя базы нет привилегии LOCK TABLES, нужной для консистентного дампа	Выдать GRANT LOCK TABLES или запускать mysqldump с флагом --single-transaction
Белый экран после восстановления без wp-content/uploads	Бэкап делали только базы данных, без файлов — медиатека физически отсутствует	Всегда бэкапить базу данных и wp-content вместе, а не по отдельности
tar: Unexpected EOF in archive	Архив бэкапа повреждён из-за обрыва соединения или нехватки места на диске при создании	Проверять df -h перед бэкапом и сверять контрольную сумму архива после

Как выполнять mysqldump и восстановление правильно — в отдельной статье про mysqldump и restore.

Когда UpdraftPlus и bash-скрипт не подходят

База данных больше 5–10 ГБ — mysqldump без --single-transaction надолго блокирует таблицы InnoDB, нужен инструмент горячего физического копирования
Сайты с ежеминутными изменениями (форум, маркетплейс) — бэкап раз в 4 часа теряет данные между копиями, нужна репликация или бинарные логи MySQL
Хостинг без доступа к cron и SSH — bash-скрипт запустить негде, остаётся только плагин или бэкап средствами панели управления
Мультисайт WordPress с десятками поддоменов — UpdraftPlus бэкапит сеть целиком, точечное восстановление одного сайта сети через него невозможно
Юридическое требование хранить резервные копии только на территории определённой страны — облачные хранилища плагина не всегда позволяют выбрать конкретный дата-центр

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

Шифрование и целостность бэкапа

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

openssl enc -aes-256-cbc -salt -pbkdf2 \
  -in $BACKUP_DIR/db_$DATE.sql \
  -out $BACKUP_DIR/db_$DATE.sql.enc \
  -pass file:/root/.backup_key

sha256sum $BACKUP_DIR/db_$DATE.sql.enc > $BACKUP_DIR/db_$DATE.sql.enc.sha256

Подробнее о хардининге доступа к бэкапам и серверу — в статье про защиту WordPress.

Как проверить, что бэкап рабочий

Разверните дамп на тестовом сервере: команда должна завершиться без ошибок и без пропущенных таблиц
Сверьте контрольную сумму архива против сохранённой при создании — расхождение означает битый файл
Откройте сайт на staging-копии и убедитесь, что все записи и медиафайлы на месте
Проверьте, что задача реально выполняется по расписанию, а не просто прописана в crontab

# Восстановление и сверка контрольной суммы
sha256sum -c db_$DATE.sql.enc.sha256
mysql -u user -p test_db < db_$DATE.sql

# Проверка, что cron реально отработал
grep wp-backup /var/log/syslog | tail -5

Чтобы протестировать восстановление без риска для рабочего сайта, используйте отдельную staging-среду.