Бэкап БД

Резервное копирование базы данных — создание копий данных для восстановления после аппаратного сбоя, ошибки разработчика или атаки. Репликация не заменяет бэкап: реплика немедленно копирует удалённые данные. Бэкап — единственная защита от случайного DROP TABLE.

Методы резервного копирования

Логический (SQL-дамп)

Экспорт SQL-команд: mysqldump для MySQL/MariaDB, pg_dump для PostgreSQL. Читаем человеком. Медленный для больших БД (>50 ГБ). Переносим между версиями СУБД.

Физический

Копирование файлов БД: pg_basebackup для PostgreSQL, Percona XtraBackup для MySQL. Быстрее при больших объёмах, но зависит от версии СУБД. Percona XtraBackup делает hot backup без блокировки таблиц.

Point-in-Time Recovery (PITR)

Полный бэкап + непрерывная запись WAL (PostgreSQL) или бинлога (MySQL). Позволяет восстановиться на любой момент времени. Минимальная потеря данных.

Правило 3-2-1

• 3 копии данных (основная + 2 бэкапа).
• 2 разных носителя (локальный диск + облачное хранилище).
• 1 копия offsite (вне основного дата-центра).

Практические команды

# PostgreSQL: дамп одной базы
pg_dump -U postgres dbname > backup.sql

# PostgreSQL: сжатый дамп
pg_dump -U postgres dbname | gzip > backup_$(date +%Y%m%d).sql.gz

# PostgreSQL: дамп всех баз
pg_dumpall -U postgres > all_databases.sql

# MySQL: дамп без блокировки (InnoDB)
mysqldump -u root -p --single-transaction dbname > backup.sql

# Восстановление MySQL
mysql -u root -p dbname < backup.sql

RTO и RPO

RTO (Recovery Time Objective) — максимально допустимое время восстановления. RPO (Recovery Point Objective) — максимально допустимая потеря данных. Для RPO = 0 нужна синхронная репликация. Для RPO = 1 час — PITR с часовым интервалом архивации WAL. Для RPO = 24 часа — ежедневный pg_dump.

Автоматизация бэкапов

Бэкапы через cron:

# Ежедневный бэкап PostgreSQL в 3:00
0 3 * * * pg_dump -U postgres mydb | gzip > /backups/mydb_$(date +%Y%m%d).sql.gz
# Удаление бэкапов старше 30 дней
0 4 * * * find /backups/ -name "*.sql.gz" -mtime +30 -delete

Хранение бэкапов: облачное хранилище (S3, Яндекс Object Storage) через rclone или aws s3 cp. BorgBackup — дедупликация и шифрование для более объёмных бэкапов.

На что обращать внимание

Проверяйте бэкапы регулярно — бэкап без проверки восстановления бесполезен. Запускайте тестовое восстановление раз в месяц на staging-сервере. Мониторинг бэкапов: Grafana + алерт при отсутствии свежего файла в хранилище. Для баз >100 ГБ логический дамп может занимать часы — переходите на физический бэкап или BorgBackup.

Проверка бэкапа

Восстановление PostgreSQL для проверки:

# Создать временную БД
createdb -U postgres testdb
# Восстановить из бэкапа
psql -U postgres testdb < backup.sql
# Проверить количество строк
psql -U postgres testdb -c "SELECT COUNT(*) FROM main_table;"
# Удалить тестовую БД
dropdb -U postgres testdb

Автоматическая проверка восстановления еженедельно — лучшая практика для production. Нередко обнаруживается, что бэкап есть, а восстановление не работает из-за несовместимости версий или битого архива.