Автоматические бэкапы WordPress: Стратегия, которая спасёт ваш сайт

Резервное копирование WordPress — это не опция, а обязательная часть инфраструктуры. Каждый сайт ежедневно сталкивается с рисками: обновления плагинов могут сломать функциональность, действия пользователей — удалить критичные данные, а сбои сервера — привести к потере всего контента. При этом 80% сайтов либо не имеют бэкапов вообще, либо полагаются только на резервные копии хостинга — без контроля и без проверки восстановления.

В этом руководстве разберём, как организовать надёжную систему автоматического резервного копирования WordPress. С настройкой скриптов через cron, хранением в облаке (Backblaze B2, Amazon S3) и обязательной проверкой восстановления. Потому что бэкап, который ни разу не восстанавливали — это не бэкап. Это предположение.

Почему «хостинг делает бэкапы» — это ловушка

Первое, что я слышу от клиентов: «Да у меня хостинг бэкапит, зачем мне париться». Знакомо? Вот три причины, почему это опасная иллюзия:

Причина №1: Бэкапы хостинга — не ваши бэкапы

Когда хостинг делает бэкап, он принадлежит хостингу. Не вам. Если вы случайно удалите файл, а потом хостинг сделает бэкап — в новом бэкапе файла уже не будет. Если хостинг решит удалить ваш аккаунт (да, такое бывает, даже у крупных) — бэкапы удалятся вместе с ним.

Правило простое: бэкап, который вы не контролируете — это не бэкап.

Причина №2: Хостинг хранит бэкапы на том же сервере

Большинство хостингов (особенно shared) хранят бэкапы на том же физическом сервере, где лежит ваш сайт. Если сервер сгорит, сломается диск, или его взломают — вы потеряете и сайт, и бэкапы одновременно.

Это как хранить запасные ключи от машины в бардачке той же машины. Угнали машину — потеряли и ключи.

Причина №3: Бэкапы хостинга — для хостинга, не для вас

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

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

Стратегия 3-2-1: золотой стандарт бэкапов

Есть правило, которое используют все, кто хоть раз потерял данные. Называется стратегия 3-2-1. Звучит сложно, но на самом деле всё просто:

  • 3 копии данных — оригинал плюс два бэкапа
  • 2 разных типа носителей — например, локальный диск и облако
  • 1 копия вне площадки — в другом городе, стране, или хотя бы в другом дата-центре

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

Как применить 3-2-1 к WordPress:

Для нашего случая стратегия выглядит так:

  1. Оригинал — ваш сайт на хостинге
  2. Бэкап №1 — ежедневный автоматический бэкап на том же хостинге (но в другой папке)
  3. Бэкап №2 — еженедельный бэкап, который улетает в облако (S3, Backblaze, Google Drive)
  4. Бэкап №3 — ежемесячный бэкап на внешнем диске (или в другом облаке)

Да, это избыточно. Да, это требует настройки. Но знаете, что ещё избыточно? Потерять магазин с выручкой 500к в месяц из-за того, что поленились настроить бэкапы.

Что именно бэкапить (и что не нужно)

WordPress состоит из двух частей: файлы и база данных. Бэкапить нужно обе, но с разной частотой.

Файлы (раз в неделю достаточно)

Что входит в файлы:

  • wp-content/uploads/ — все загруженные картинки, документы, видео
  • wp-content/themes/ — ваша тема и дочерние темы
  • wp-content/plugins/ — все плагины (даже те, что можно скачать заново)
  • wp-config.php — конфигурация с паролями от базы
  • .htaccess — правила перенаправления

Что не нужно бэкапить:

  • Ядро WordPress (wp-admin/, wp-includes/) — всегда можно скачать заново
  • Кэш-папки (wp-content/cache/) — это временные файлы
  • Логи — они не нужны для восстановления

База данных (ежедневно, а лучше — перед каждым изменением)

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

Важный нюанс: бэкап базы данных весит копейки (обычно 5-50 МБ), поэтому можно делать его хоть каждый час. А вот бэкап файлов может весить гигабайты, если у вас много картинок, поэтому его делают реже.

Автоматизация: скрипт, который работает за вас

Ручные бэкапы — это миф. Вы будете делать их неделю, потом забудете, потом вспомните, когда уже поздно. Поэтому бэкапы должны быть автоматическими.

Напишем простой bash-скрипт, который делает всё сам. Создаём файл /usr/local/bin/wp-backup.sh:

#!/bin/bash

# Конфигурация
SITE_DIR="/var/www/wordpress"
BACKUP_DIR="/backup/wordpress"
DB_NAME="your_database_name"
DB_USER="your_database_user"
DB_PASS="your_database_password"
DATE=$(date +%Y-%m-%d_%H-%M)
RETENTION_DAYS=30

# Создаём папку для бэкапа, если её нет
mkdir -p $BACKUP_DIR

# Бэкап базы данных
echo "[$DATE] Starting database backup..."
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/db_$DATE.sql.gz

if [ $? -eq 0 ]; then
    echo "[$DATE] Database backup completed"
else
    echo "[$DATE] ERROR: Database backup failed"
    exit 1
fi

# Бэкап файлов (исключая кэш и логи)
echo "[$DATE] Starting files backup..."
tar -czf $BACKUP_DIR/files_$DATE.tar.gz \
    --exclude='wp-content/cache' \
    --exclude='wp-content/uploads/backupbuddy_temp' \
    --exclude='*.log' \
    -C $SITE_DIR wp-content/uploads wp-content/themes wp-content/plugins wp-config.php .htaccess

if [ $? -eq 0 ]; then
    echo "[$DATE] Files backup completed"
else
    echo "[$DATE] ERROR: Files backup failed"
    exit 1
fi

# Удаляем старые бэкапы (старше 30 дней)
echo "[$DATE] Cleaning old backups..."
find $BACKUP_DIR -type f -mtime +$RETENTION_DAYS -delete

echo "[$DATE] Backup process completed successfully"
echo "Backup size: $(du -sh $BACKUP_DIR | cut -f1)"

Разберём, что здесь происходит:

  • mysqldump — экспортирует базу данных в SQL-файл, потом сжимает через gzip (экономия 80% места)
  • tar — архивирует файлы, исключая кэш и логи (они не нужны)
  • find -mtime +30 -delete — удаляет бэкапы старше 30 дней, чтобы диск не забился

Делаем скрипт исполняемым:

chmod +x /usr/local/bin/wp-backup.sh

Теперь добавляем его в cron, чтобы запускался автоматически каждый день в 3 часа ночи:

# Открываем crontab
crontab -e

# Добавляем строку
0 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

Всё. Теперь каждый день в 3 часа ночи ваш сайт автоматически бэкапится. Вы спите — скрипт работает. Красота.

Хранение в облаке: чтобы не потерять всё сразу

Локальные бэкапы — это хорошо. Но если сервер сгорит, сгорят и бэкапы. Поэтому нужна копия в облаке. Вариантов масса, но я рекомендую два:

Вариант А: Backblaze B2 (дешевле некуда)

Backblaze B2 — это S3-совместимое хранилище, которое стоит $5 за 1 ТБ в месяц. В 5 раз дешевле Amazon S3. Для большинства сайтов 1 ТБ хватит на годы.

Как настроить:

  1. Регистрируемся на backblaze.com/b2
  2. Создаём bucket (контейнер для файлов), например wp-backups
  3. Получаем Application Key ID и Application Key
  4. Устанавливаем утилиту b2 на сервер:
    pip3 install b2
b2 authorize-account YOUR_KEY_ID YOUR_KEY
  5. Добавляем в наш скрипт бэкапа отправку в облако:
    # После создания локального бэкапа
echo "[$DATE] Uploading to Backblaze B2..."
b2 upload-file wp-backups $BACKUP_DIR/db_$DATE.sql.gz db_$DATE.sql.gz
b2 upload-file wp-backups $BACKUP_DIR/files_$DATE.tar.gz files_$DATE.tar.gz

Всё. Теперь бэкапы автоматически улетают в облако. Даже если сервер сгорит, бэкапы останутся в Backblaze.

Вариант Б: Amazon S3 (если нужна максимальная надёжность)

Amazon S3 дороже ($23 за 1 ТБ), но у него больше дата-центров и выше SLA. Если вы храните критичные данные — S3 ваш выбор.

Настройка аналогична, только используем утилиту aws cli:

# Установка AWS CLI
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# Конфигурация
aws configure

# Отправка в скрипте
aws s3 cp $BACKUP_DIR/db_$DATE.sql.gz s3://your-bucket-name/db_$DATE.sql.gz
aws s3 cp $BACKUP_DIR/files_$DATE.tar.gz s3://your-bucket-name/files_$DATE.tar.gz

Вариант В: Google Drive (для тех, кто не любит терминал)

Если вы не дружите с терминалом, можно использовать плагин UpdraftPlus. Он умеет отправлять бэкапы в Google Drive, Dropbox, Amazon S3 и другие облака. Бесплатной версии хватает для большинства задач.

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

Самое важное: тестирование восстановления

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

Бэкап, который ни разу не восстанавливали — это не бэкап. Это надежда.

Поэтому раз в месяц (или хотя бы раз в квартал) нужно брать свежий бэкап и разворачивать его на тестовом сервере. Это занимает 30 минут, но спасает от паники в критический момент.

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

  1. Поднимите локальный сервер (через Docker или Local by Flywheel)
  2. Скачайте свежий бэкап из облака
  3. Разархивируйте файлы:
    tar -xzf files_2026-06-15_03-00.tar.gz -C /var/www/test-site/
  4. Импортируйте базу:
    mysql -u root -p test_database < db_2026-06-15_03-00.sql
  5. Обновите wp-config.php — укажите новые данные для базы
  6. Откройте сайт в браузере — всё должно работать

Если что-то не работает — разбирайтесь, почему. Может, скрипт бэкапа сломался, может, облако не отдаёт файлы, может, версия MySQL несовместима. Лучше узнать об этом сейчас, чем в момент, когда сайт лежит и каждый час стоит денег.

Мониторинг: чтобы знать, что бэкапы работают

Автоматизация — это хорошо. Но что если скрипт сломается? Или облако перестанет принимать файлы? Вы не узнаете, пока не станет поздно.

Поэтому нужен мониторинг. Самый простой способ — отправлять уведомление в Telegram после каждого бэкапа.

Добавляем в конец скрипта:

# Telegram notification
TELEGRAM_BOT_TOKEN="your_bot_token"
TELEGRAM_CHAT_ID="your_chat_id"

BACKUP_SIZE=$(du -sh $BACKUP_DIR | cut -f1)
LATEST_BACKUP=$(ls -t $BACKUP_DIR/*.tar.gz | head -1)

MESSAGE="✅ WordPress backup completed
Site: custom-code.ru
Time: $DATE
Size: $BACKUP_SIZE
Latest: $(basename $LATEST_BACKUP)"

curl -s -X POST https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage \
    -d chat_id=$TELEGRAM_CHAT_ID \
    -d text="$MESSAGE"

Теперь после каждого бэкапа вам приходит сообщение в Telegram. Если сообщение не пришло — значит, что-то сломалось. Пора чинить.

Для более продвинутого мониторинга можно использовать Uptime Kuma или написать скрипт, который проверяет размер последнего бэкапа и алертит, если он подозрительно мал (значит, что-то не забэкапилось).

Чек-лист: всё ли у вас настроено

Пройдитесь по этому списку. Если хотя бы один пункт не выполнен — бэкапы у вас неправильные.

  • ✅ Бэкапы делаются автоматически (через cron или плагин)
  • ✅ База данных бэкапится ежедневно
  • ✅ Файлы бэкапятся еженедельно
  • ✅ Минимум одна копия хранится вне сервера (облако, внешний диск)
  • ✅ Старые бэкапы автоматически удаляются (чтобы диск не забился)
  • ✅ Вы хотя бы раз тестировали восстановление из бэкапа
  • ✅ Настроен мониторинг (уведомления об успешных/неуспешных бэкапах)
  • ✅ Пароли от базы и облака хранятся в безопасном месте (не в коде!)
  • ✅ Бэкапы зашифрованы (если храните чувствительные данные)

Если хотя бы три пункта не выполнены — вы в зоне риска. Потратьте выходные на настройку. Это спасёт вам кучу нервов в будущем.

Решение частых проблем

Бэкап весит слишком много (10+ ГБ)

Обычно проблема в папке uploads/. Там могут лежать:

  • Оригиналы картинок в полном размере (до оптимизации) — удалите их, оставьте только оптимизированные версии
  • Видео — храните видео на YouTube/Vimeo, а не на сервере
  • Старые бэкапы плагинов (BackupBuddy, UpdraftPlus) — удалите их

После очистки размер бэкапа обычно уменьшается в 3-5 раз.

Бэкап не восстанавливается (ошибка базы данных)

Частая причина — несовместимость версий MySQL. Если вы делали бэкап на MySQL 8.0, а восстанавливаете на 5.7 — могут быть проблемы с синтаксисом. Решение: указывайте совместимый формат при экспорте:

mysqldump --compatible=mysql57 -u user -p database > backup.sql

Облако не принимает файлы (ошибка авторизации)

Проверьте:

  • Не истёк ли API-ключ (некоторые облака требуют обновления ключей раз в год)
  • Не закончилось ли место в bucket
  • Правильно ли указаны права доступа (bucket должен быть доступен для записи)

Cron не запускает скрипт

Проверьте логи:

# Смотрим логи cron
grep CRON /var/log/syslog

# Проверяем, есть ли скрипт в crontab
crontab -l

# Тестируем скрипт вручную
/usr/local/bin/wp-backup.sh

Если скрипт работает вручную, но не через cron — проблема в правах. Убедитесь, что пользователь, от которого запускается cron, имеет права на выполнение скрипта и доступ к папкам.

Итог

Бэкапы — это не опция. Это обязательная часть любого сайта, который вы не хотите потерять. Хорошая новость: настроить автоматические бэкапы не так уж сложно. 30 минут на скрипт, час на настройку облака, и вы спите спокойно.

Помните стратегию 3-2-1: три копии, два носителя, одна вне площадки. Автоматизируйте всё, что можно. Тестируйте восстановление хотя бы раз в квартал. И настройте мониторинг, чтобы знать, что бэкапы работают.

И самое главное: не откладывайте. Прямо сейчас откройте терминал и проверьте, есть ли у вас бэкапы. Если нет — начните с простого: настройте cron-скрипт и отправку в Backblaze. Это займёт меньше времени, чем чтение этой статьи до конца.

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

Это и есть профессионализм. Не умение писать код. А умение спать спокойно.

Теги:
WordPress Резервное копирование