Стратегія 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-середовище.