Настройка инкрементального бэкапирования базы данных

Настройка инкрементального бэкапирования базы данных

Мы настраиваем инкрементальные бэкапы для PostgreSQL и MySQL — под ваш стек и нагрузку. Полные дампы каждую ночь — дорого по дисковому пространству и времени. Когда база занимает десятки гигабайт, полный дамп может длиться часы и создавать нагрузку на диск. Например, полный дамп базы 500 ГБ на HDD может занять 8 часов, а инкрементальный — 15 минут. Инкрементальные бэкапы сохраняют только изменения с последнего бэкапа, сокращая время и объём в 10–50 раз. Экономия дискового пространства достигает 80%, а время восстановления сокращается в 2–5 раз. Мы используем только проверенные инструменты: pgBackRest для PostgreSQL, Percona XtraBackup для MySQL, а для облачного хранения — Restic с дедупликацией. Все решения сопровождаются мониторингом и алертингом. Дополнительно снижается нагрузка на диск и CPU. Мы гарантируем, что после настройки вы будете спать спокойно — данные в безопасности, а восстановление займёт минуты.

Какой тип инкрементального бэкапа выбрать?

Differential — сохраняет все изменения с последнего полного бэкапа. Восстановление: полный + один differential. Incremental — сохраняет только изменения с последнего любого бэкапа. Восстановление: полный + цепочка incremental. WAL-based (PostgreSQL) — непрерывная архивация журналов транзакций, основа для PITR. Incremental эффективнее Differential по размеру — он хранит только дельту, но сложнее в восстановлении: нужна цепочка. На практике рекомендуем комбинацию: полный раз в неделю, дифференциальный ежедневно — баланс размера и скорости восстановления.

Как настроить WAL-архивацию в PostgreSQL?

Установите pgBackRest и настройте конфиг:

# /etc/pgbackrest/pgbackrest.conf [global] repo1-path=/var/lib/pgbackrest repo1-retention-full=2 repo1-retention-diff=7 log-level-console=info [myapp] pg1-path=/var/lib/postgresql/14/main 

Выполните инициализацию и первый полный бэкап:

# Инициализация stanza и первый полный бэкап pgbackrest --stanza=myapp stanza-create pgbackrest --stanza=myapp --type=full backup # Расписание в cron: полный раз в неделю, дифференциальный ежедневно # Полный (воскресенье 01:00) 0 1 * * 0 pgbackrest --stanza=myapp --type=full backup # Дифференциальный (пн-сб 01:00) 0 1 * * 1-6 pgbackrest --stanza=myapp --type=diff backup 

Для MySQL используйте Percona XtraBackup:

# Полный бэкап xtrabackup --backup --target-dir=/var/backups/mysql/full/ # Инкрементальные на основе предыдущего xtrabackup --backup --target-dir=/var/backups/mysql/incr1/ \ --incremental-basedir=/var/backups/mysql/full/ xtrabackup --backup --target-dir=/var/backups/mysql/incr2/ \ --incremental-basedir=/var/backups/mysql/incr1/ # Восстановление: подготовка полного + применение инкрементов xtrabackup --prepare --apply-log-only --target-dir=/var/backups/mysql/full/ xtrabackup --prepare --apply-log-only \ --target-dir=/var/backups/mysql/full/ \ --incremental-dir=/var/backups/mysql/incr1/ xtrabackup --prepare \ --target-dir=/var/backups/mysql/full/ \ --incremental-dir=/var/backups/mysql/incr2/ 

Облачное хранилище и дедупликация

Для хранения бэкапов в облаке используйте Restic — он поддерживает S3, GCS, B2 и шифрование на лету:

# Инициализация репозитория restic -r s3:s3.amazonaws.com/my-bucket/db-backups init # Бэкап директории с дампами restic -r s3:s3.amazonaws.com/my-bucket/db-backups \ backup /var/backups/postgres/ \ --password-file /etc/restic-password 

Restic автоматически дедуплицирует блоки, что сокращает объём хранилища ещё на 30–50% поверх сжатия.

Как настроить мониторинг и алертинг?

Критические метрики: размер последнего бэкапа (резкое уменьшение — сигнал проблемы), время выполнения, успешность. Используйте Healthchecks.io для проверки:

# Конец скрипта — проверка и healthcheck if pgbackrest --stanza=myapp check; then curl -s "https://hc-ping.com/${HC_UUID}" else curl -s "https://hc-ping.com/${HC_UUID}/fail" fi 

Дополнительно настройте сбор метрик через Prometheus и дашборды Grafana. Это позволит видеть тенденции и вовремя реагировать.

Типичные ошибки при настройке

• Не настроена ротация бэкапов. Старые бэкапы не удаляются, диск переполняется. Укажите retention в pgBackRest или скриптах.
• Забыли про мониторинг. Если бэкап не выполнился, вы узнаете об этом только когда данные потеряны. Настройте алерты.
• Игнорирование тестового восстановления. Бэкап может быть битым. Регулярно восстанавливайте на тестовом сервере.
• Выбор неправильного типа. Для больших баз с частыми изменениями WAL-архивация предпочтительнее.

Как мы тестируем восстановление?

Каждый настроенный бэкап мы проверяем на восстановление в staging-среде. Создаём копию базы, выполняем полное восстановление и сверяем контрольные суммы. Используем скрипты автоматической проверки, которые запускаются после каждого бэкапа. Это гарантирует, что данные можно восстановить в любой момент. В runbook описываем точную последовательность команд для восстановления.

Что входит в настройку

• Аудит текущей схемы бэкапов и нагрузочное тестирование
• Выбор оптимальной стратегии (полный + дифференциальный или WAL)
• Настройка инструмента (pgBackRest, XtraBackup) под вашу СУБД
• Создание скриптов ротации и очистки
• Интеграция мониторинга и алертинга (Healthchecks.io, Prometheus)
• Документация по восстановлению (runbook)
• Обучение вашей команды основам администрирования

Мы настроили инкрементальные бэкапы для более чем 50 проектов — от стартапов до enterprise. За 5 лет работы ни один бэкап не подвёл: все данные восстанавливаются по первому запросу. Гарантируем восстановление данных при соблюдении регламента. Оценим ваш проект за 1 день. Получите консультацию по настройке бэкапов — мы подберём стратегию под вашу инфраструктуру.

Срок выполнения

Настройка pgBackRest или XtraBackup с инкрементальной стратегией — 1–2 рабочих дня.