Стратегия резервного копирования сайта: полное и инкрементное копирование, частота, места хранения и учебное восстановление
1. Что копировать: базу данных и файлы нужно резервировать отдельно
У сайта нужно резервировать две категории данных: базу данных и файлы. База данных — это содержимое WordPress: wp_posts, wp_options, wp_users. Файлы — это изображения, темы и код плагинов в wp-content/uploads. Эти две категории меняются с разной частотой и резервируются по-разному, поэтому общее копирование приведёт к проблемам.
Базу данных выгружайте через mysqldump или wp-cli, каждый раз с параметром –single-transaction, чтобы не блокировать таблицы и не влиять на работу сайта. Файлы синхронизируйте инкрементно через rsync — только изменившиеся части, не копируйте всё целиком каждый раз. Полное копирование каталога wp-content на 10 ГБ занимает больше десяти минут, а инкрементная синхронизация — несколько секунд.
| Объект резервного копирования | Частота изменений | Рекомендуемые инструменты | Способ резервного копирования |
|---|---|---|---|
| База данных MySQL | Может меняться каждый час | mysqldump или xtrabackup | Инкремент binlog каждые 4 часа, полный дамп ежедневно |
| wp-content/uploads | Новые изображения каждую неделю | rsync | Инкрементная синхронизация ежедневно |
| Код тем и плагинов | Меняется несколько раз в месяц | git или rsync | Контроль версий, полная копия ежемесячно |
| wp-config.php | Меняется крайне редко | Хранить отдельно в менеджере паролей | Копировать при каждом изменении |
| Конфигурация nginx/сайта | Меняется несколько раз в месяц | Управление через git | Копировать при каждом изменении |
Пример из практики: сайт промышленного оборудования на WordPress для выхода на зарубежные рынки, ежедневно добавляется 3–5 заявок и 2–3 фотографии продукции. База данных выгружается скриптом каждые 4 часа, файлы инкрементно синхронизируются через rsync в 3 часа ночи в объектное хранилище вне офиса. За неделю резервные копии базы занимают около 500 МБ, инкрементные копии файлов — около 200 МБ, общие расходы на хранение — меньше 20 рублей в месяц. Такая схема надёжнее любого платного плагина резервного копирования.
Как написать скрипт резервного копирования — та же логика, что и в Технологический стек crater тот же подход к автоматизации, что и в остальном администрировании: без GUI-плагинов, через cron и скрипты, а при сбое — оповещение.
2. Частота и политика хранения: чем чаще, тем не всегда лучше
Контринтуитивный вывод: чем чаще бэкап, тем лучше — это не так. Слишком частые бэкапы съедают много места и IO, а при восстановлении становится только хуже: перед вами куча почти одинаковых копий, и непонятно, какая из них чистая. Разумная частота зависит от скорости изменений в бизнесе: базу данных — раз в 4 часа, потому что заявки могут прийти в любой момент; файлы — раз в день, потому что картинки загружаются нечасто.
Стратегия хранения строится по схеме дед-отец-сын: ежедневные бэкапы храним 30 дней, еженедельные — 12 недель, ежемесячные — 12 месяцев, ежегодные — 3 года. Так вы сможете восстановить и статью, случайно удалённую вчера, и чистую версию полугодовой давности — до того, как сайт взломали.
| Тип бэкапа | Частота | Срок хранения | место хранения | Зачем нужен |
|---|---|---|---|---|
| Полный бэкап базы | Ежедневно в 3:00 | 30 дней | Удалённое объектное хранилище | Восстановление после случайного удаления |
| Инкрементный binlog базы данных | Каждые 4 часа | 7 дней | Локально + удалённо | Восстановление с точностью до минуты |
| Полный бэкап файлов | Каждое воскресенье ночью | 12 недель | Удалённое объектное хранилище | Откат на уровне недели |
| Инкрементный rsync файлов | Ежедневно ночью | 30 дней | Удалённое объектное хранилище | Откат на уровне дня |
| Ежемесячный архив | 1-го числа каждого месяца | 12 месяцев | Холодный бэкап Glacier | Ежемесячное соответствие и долгосрочное хранение |
| Ежегодный архив | Каждый январь | 3 года | Холодный бэкап Glacier | Ежегодный аудит и история |
Пример из жизни: 15 марта днём на сайте для зарубежных рынков обнаружили, что в базу данных внедрён вредоносный код. Благодаря инкрементному бэкапу binlog базу можно восстановить на 12:00 15 марта — состояние до атаки, потеряв лишь половину дня заявок. Если бы был только ежедневный полный бэкап, восстановление откатило бы на 3:00 15 марта, и вы потеряли бы заявки за целый день. Вот в чём разница между инкрементом раз в 4 часа и полным бэкапом раз в день.
Три. Место хранения: принцип 3-2-1, удалённая копия обязательна
Принцип резервного копирования 3-2-1 означает: важные данные хранятся в 3 копиях, на 2 разных носителях, и 1 копия находится в удалённом месте. Это не теория, а вывод из бесчисленных случаев с программами-вымогателями. В реальных авариях злоумышленники шифруют сервер и заодно локальные бэкапы — потому что бэкап и сайт лежат на одной машине.
Как выбрать из трёх уровней хранения: первый — локальный бэкап, на другом дисковом разделе сервера, восстанавливается быстрее всего, но хуже всего защищает от рисков; второй — удалённое объектное хранилище, AWS S3 или Alibaba Cloud OSS, с резервированием между зонами доступности, не боится падения одного сервера; третий — холодный архив, S3 Glacier или архив OSS, дёшево, но восстанавливается медленно, для ежегодного соответствия и долгосрочного хранения.
| Уровень хранения | Позиция | Скорость восстановления | Затраты | Основное назначение |
|---|---|---|---|---|
| Локальный бэкап на диск | Другой раздел сервера | Секунды | 0 ₽ | Быстрое повседневное восстановление |
| Удалённое объектное хранилище | S3/OSS между зонами | Минуты | Около 0,02 ₽/ГБ/мес. | Основной бэкап, ежедневная синхронизация |
| Холодный архив | Архив Glacier/OSS | От часов до дней | Около 0,005 ₽/ГБ/мес. | Ежегодное соответствие и долгосрочное хранение |
| Офлайн-носитель | Локальный диск/лента | Физическое извлечение диска | Разовая стоимость диска | Подстраховка на случай крайнего вымогательства |
Контринтуитивное напоминание: не храните резервные копии в веб-каталоге. Многие кладут бэкапы в wp-content/backup/, думая, что так надёжнее, но на самом деле атакующий находит этот путь и просто скачивает файлы — имена базы данных и таблиц утекают целиком. Правильно: хранить бэкапы вне корня сайта либо после создания автоматически загружать их в объектное хранилище и удалять локальную копию. Про очистку после взлома читайте После взлома сайта.
и Глобальное ускорение CDN Важно учитывать: кэш CDN — это не резервная копия. Он лишь копирует статический контент на периферийные узлы, а если origin упал, кэш CDN тоже устареет. Не считайте кэш CDN решением для аварийного восстановления.
Четвёртое: учебное восстановление — раз в квартал, чтобы убедиться, что бэкап действительно рабочий
Самый недооценённый этап стратегии резервного копирования — учебное восстановление. У многих компаний скрипты бэкапа работают год, но восстановление не проводилось ни разу, и только при аварии выясняется, что файлы повреждены, пароль от архива забыт или процесс восстановления вообще не работает. В реальных инцидентах более 40% восстановлений из бэкапа заканчиваются неудачей, и причины всегда из этих трёх категорий.
Как проводить учебное восстановление: раз в квартал выбирайте окно обслуживания, выгружайте свежий бэкап из удалённого объектного хранилища, разворачивайте его в совершенно новой тестовой среде и прогоняйте весь процесс — «восстановить файлы, импортировать базу данных, настроить nginx, открыть сайт, проверить отправку формы заявки». Засеките время и зафиксируйте фактические RTO (целевое время восстановления) и RPO (объём потерянных данных). Как определять RTO/RPO, читайте 独立站灾难恢复与RTO/RPO定义.
| Шаги учебного восстановления | Действие | Критерии приёмки | Частые точки отказа |
|---|---|---|---|
| 1. Получить резервную копию | Скачать последний полный и инкрементальный бэкап из S3 | Скачивание завершено за 5 минут | Учётные данные объектного хранилища истекли |
| 2 Проверка распаковки | tar -tzf выводит список файлов | Количество файлов полное, повреждений нет | Архив gzip повреждён, проверка не проводилась |
| 3 Восстановление файлов | Распаковать в веб-каталог тестовой среды | Права корректны: 755/644 | Права потеряны, сайт показывает белый экран |
| 4 Импорт базы данных | mysql < backup.sql | Количество таблиц совпадает с продакшеном | Неверная кодировка, китайский текст превращается в кракозябры |
| 5 Настройка nginx | Скопировать конфигурацию и сменить порт | Домен открывается | Правила ЧПУ потеряны |
| 6 Проверка функций | Пройти отправку формы заявки | Письмо получено, запись попала в CRM | Пароль SMTP прописан в конфигурации жёстко |
Пример из практики: команда полгода не проводила учебное восстановление, диск сервера вышел из строя, и только тогда они полезли за удалённым бэкапом. Распаковка оборвалась на середине с ошибкой — оказалось, три месяца назад в скрипте бэкапа был неверный параметр gzip, и все копии за последующие два месяца повреждены. В итоге восстановились из более раннего чистого бэкапа и потеряли два месяца контента. Такой инцидент выявился бы заранее, если запускать учебное восстановление раз в квартал.
Как настроить мониторинг бэкапов, читайте Мониторинг сайта и оповещения: при сбое задачи бэкапа отправлять оповещение в WeCom, при резком падении размера файла бэкапа — оповещение, при возрасте бэкапа более 24 часов — оповещение. Список для ежедневного обслуживания смотрите Шесть задач на месяц в период обслуживания сайта.
FAQ: частые вопросы
独立站备份用什么插件，UpdraftPlus够吗？
Какую частоту резервного копирования выбрать, нужно ли делать бэкап каждый час?
Как применить принцип резервного копирования 3-2-1 на практике?
Как проводить учения по восстановлению и как часто?
Нужно ли шифровать файлы резервных копий и как хранить ключи?
Как узнать, что скрипт резервного копирования упал, и как настроить оповещения?
В заключение
В резервном копировании хуже всего установка плагина с мыслью, что на этом всё. Плагин работает каждый день, файлы бэкапов создаются каждый день, но восстановление ни разу не проводилось — и когда случается авария, выясняется, что бэкап повреждён, пароль потерян, а процесс не работает. Стратегия резервного копирования наполовину о том, как хранить, а наполовину о том, как восстанавливать, — и второе в десять раз важнее первого.
Три шага к внедрению: первый — выстройте три уровня резервного копирования по принципу 3-2-1: локальная копия, удалённое объектное хранилище и холодный архив; второй — определите частоту и политику хранения: для базы данных инкрементный бэкап каждые 4 часа плюс ежедневный полный, для файлов ежедневный инкрементный, хранение от 30 дней до 3 лет; третий — раз в квартал проводите учения по восстановлению, полностью проходите процесс восстановления в тестовой среде и фиксируйте фактические RTO и RPO. Только после этих трёх шагов вы можете сказать, что у вас есть бэкапы.
Запомните одну фразу: бэкап, который ни разу не восстанавливали, равен отсутствию бэкапа — год работы скрипта резервного копирования не стоит одного полного учения по восстановлению, а в реальных авариях 40% бэкапов в решающий момент не открываются.