У резервных копий есть неприятное свойство: их ценность становится понятна ровно тогда, когда настраивать их уже поздно. Взломанный плагин, неудачное обновление, случайно удалённая страница, провайдер, который потерял диск: каждая из этих ситуаций заканчивается либо восстановлением за полчаса, либо неделями пересборки сайта с нуля.
Коротко
Что получится
- Схема 3-2-1: копия на сервере и копия у другого провайдера
- Ночной скрипт: база, файлы и удаление копий старше 14 дней
- Проверенное восстановление и ваше реальное время отката
Что понадобится
- Сайт на своём сервере и права root
- S3-совместимое хранилище у другого провайдера
- Около часа на настройку
Содержание
Правило 3-2-1
Базовая схема, которую рекомендуют агентства по кибербезопасности, называется правилом 3-2-1:
Для сайта на своём сервере это выглядит так: сам сайт, ежедневная копия на том же сервере для быстрого отката и копия у другого провайдера на случай, если пропадёт весь сервер.
Такая копия защищает от ошибок, но не от потери сервера, взлома с правами root или ошибки провайдера. А копия, которую ни разу не проверяли, - это надежда, а не резервная копия.
Что копировать
Для сайта на WordPress:
| Что | Где лежит | Как часто меняется |
|---|---|---|
| База данных | MariaDB или MySQL | при каждой публикации, комментарии, заказе |
| Загруженные файлы | wp-content/uploads | при загрузке картинок |
| Темы и плагины | wp-content/themes, wp-content/plugins | при обновлениях |
| Настройки | wp-config.php | редко |
| Конфигурация сервера | /etc/nginx, /etc/php | редко |
Ядро WordPress копировать не обязательно: его можно скачать заново. Но весь каталог сайта обычно небольшой, и копировать его целиком проще.
Для статичного сайта достаточно копии каталога с файлами. Если сайт генерируется из исходников, храните исходники в репозитории: это уже резервная копия.
Как часто делать копии
Частота определяется одним вопросом: сколько данных вы готовы потерять?
Сайт-визитка
Меняется раз в месяц: еженедельной копии достаточно, плюс копия перед каждым изменением.
Блог
С регулярными публикациями: ежедневная копия базы и еженедельная копия файлов.
Магазин или сайт с заявками
База данных минимум раз в сутки, лучше чаще. Потерянный день заказов стоит дороже любого хранилища.
Перед обновлением ядра, темы или плагинов делайте отдельную копию. Это самая частая точка, откуда приходится откатываться.
Храните не одну последнюю копию, а цепочку: например, 14 ежедневных и 8 еженедельных. Если сайт взломали неделю назад, а заметили только сейчас, последняя копия уже содержит вредоносный код.
1Скрипт копирования на сервере
Простой скрипт покрывает базу, файлы и удаление старых копий. Создайте файл /root/backup-site.sh:
Подсвеченные значения замените на свои: example.com - это ваш сайт.
#!/bin/bash
set -euo pipefail
SITE=/var/www/example.com
DEST=/root/backups/example.com
DATE=$(date +%F)
mkdir -p "$DEST"
# выгрузка базы
wp --path="$SITE" db export "$DEST/db-$DATE.sql" --allow-root
# архив файлов сайта
tar -czf "$DEST/files-$DATE.tar.gz" -C "$SITE" .
# удаление копий старше 14 дней
find "$DEST" -type f -mtime +14 -deleteСделайте его исполняемым:
chmod 700 /root/backup-site.shИ добавьте в расписание через crontab -e:
30 3 * * * /root/backup-site.sh >> /var/log/backup-site.log 2>&1Каждую ночь в 3:30 скрипт выгрузит базу, упакует файлы и удалит копии старше 14 дней.
В выгрузке базы лежат хеши паролей и данные пользователей.
2Копия вне сервера
Для копии вне площадки удобно объектное хранилище S3-совместимого типа: оно есть у большинства облачных провайдеров и стоит недорого за гигабайт. Копировать туда удобно утилитой rclone, которая поддерживает десятки хранилищ:
apt install -y rclone
rclone configПосле настройки подключения, например с именем backup, добавьте в конец скрипта одну строку:
rclone copy "$DEST" backup:site-backups/example.com --max-age 25hТри правила для удалённой копии:
Снимки сервера у провайдера - хорошее дополнение, но не замена: они обычно хранятся в том же аккаунте и пропадут вместе с ним.
3Проверка восстановления
Самый пропускаемый и самый важный шаг. Раз в месяц или хотя бы раз в квартал восстановите сайт из копии на отдельной площадке.
Удобно тестовое окружение на том же сервере, но на отдельном поддомене и с запретом индексации, чтобы копия не попала в поиск.
1. Разверните пустой сервер или каталог и создайте тестовую базу.
2. Распакуйте файлы из архива:
mkdir -p /var/www/restore-test
tar -xzf files-2026-09-14.tar.gz -C /var/www/restore-test3. Импортируйте базу:
wp --path=/var/www/restore-test db import db-2026-09-14.sql --allow-root4. Замените адрес на тестовый, чтобы копия не ссылалась на рабочий сайт:
wp --path=/var/www/restore-test search-replace 'https://example.com' 'https://restore.example.com' --skip-columns=guid --allow-rootОткройте сайт и проверьте главную, несколько записей, вход в админку и картинки.
Засеките время. Это ваше реальное время восстановления, и лучше узнать его на тесте, а не во время аварии. Заодно проверка выявляет типичные проблемы: пустой архив из-за ошибки прав, выгрузку базы, оборванную на середине, или копии, которые перестали создаваться месяц назад.
4Следим, что копии создаются
Скрипт в расписании может молча перестать работать: закончилось место на диске, поменялся пароль базы, истёк ключ хранилища. Минимальный контроль:
Журнал
Смотрите /var/log/backup-site.log раз в неделю или настройте отправку ошибок на почту.
Размер копий
Не должен резко падать: архив, который вчера весил 500 МБ, а сегодня 2 КБ, - признак ошибки.
Свободное место на диске
Локальные копии съедают его быстрее, чем кажется.
Частые ошибки
Взлом, замеченный через неделю, уже попал в неё.
Храните цепочку, например 14 ежедневных и 8 еженедельных
Копируются только файлы, а без базы сайт на WordPress восстановить нельзя.
Выгружайте базу: wp db export
Узнать, что архив повреждён, во время аварии - худший сценарий.
Проверяйте восстановление на тесте, шаг 3
Копии с персональными данными лежат, например, в каталоге сайта.
Выгрузки базы никогда не кладите в веб-корень
Как это устроено в Kesyio
Сервер ваш, и резервные копии тоже
- Сайт на вашем сервере. Kesyio разворачивает сайты на вашем собственном сервере, поэтому данные остаются под вашим контролем, а вместе с ними и ответственность за резервные копии.
- Копии настраиваете вы. Kesyio не делает резервные копии сайтов за вас: настройте их по этой инструкции сразу после запуска сайта.
- Заполнение диска в кабинете. Проверка состояния сервера в кабинете покажет заполнение диска, чтобы локальные копии не съели всё свободное место.
Вопросы и ответы
Хватит ли плагина резервного копирования?
Для небольшого сайта плагин - рабочий вариант, если он отправляет копии во внешнее хранилище, а не хранит их в каталоге сайта. Но плагин работает внутри WordPress: если сайт взломан или не запускается, плагин тоже недоступен. Копия на уровне сервера надёжнее.
Сколько места нужно под копии?
Посмотрите размер каталога сайта и выгрузки базы, умножьте на число хранимых копий. Архивы сжимаются, но картинки и так сжаты, поэтому ориентируйтесь на размер wp-content/uploads.
Нужно ли копировать сайт, если провайдер делает снимки сервера?
Да. Снимки провайдера обычно хранятся в том же аккаунте, делаются редко и восстанавливают сервер целиком. Отдельная копия сайта у другого провайдера защищает от потери аккаунта и позволяет восстановить один сайт, не откатывая весь сервер.
Как восстановить сайт после взлома?
Восстановите сайт из копии, сделанной до взлома, а не из последней. Затем сразу смените все пароли, обновите ядро, темы и плагины и закройте уязвимость, через которую произошёл взлом, иначе он повторится. Базовые меры защиты разобраны в статье о безопасности WordPress.
Итог
- Надёжная схема - это три копии, два типа хранения и одна копия у другого провайдера.
- Ежедневный скрипт по расписанию и цепочка копий, а не одна последняя. Настройка занимает час, а сэкономить может недели.
- Начните с проверки восстановления: если завтра сервер пропадёт, из чего и за сколько вы восстановите сайт?
- Копии пригодятся и при переезде: как перенести сайт на новый сервер без простоя, разобрано в отдельной инструкции.
