Коротко: рабочие бэкапы БД — автоматический mysqldump по cron, сжатие, несколько поколений с ротацией, копия offsite (3-2-1) и проверка восстановлением.

Рабочая схема бэкапов БД — это автоматический mysqldump по расписанию (cron), сжатие и хранение нескольких поколений с ротацией, копия в другое физическое место и регулярная проверка восстановлением. Главная мысль сразу: бэкап, который ни разу не восстанавливали, бэкапом не является. Разберём по шагам.

Логический бэкап через mysqldump

mysqldump делает «логический» бэкап — SQL-файл с командами для воссоздания данных. Он прост, переносим между версиями и удобен для небольших и средних баз.

# одна база, с сжатием на лету
mysqldump --single-transaction --quick \
  -u backup_user -p'***' mydb | gzip > mydb-$(date +%F).sql.gz

Важные флаги: --single-transaction снимает консистентный снимок InnoDB без блокировки таблиц (приложение продолжает работать), --quick не держит большие таблицы в памяти. Для бэкапа заведите отдельного пользователя БД с правами только на чтение и дамп, а не root.

Автоматизация через cron

Ручные бэкапы «когда вспомню» не работают. Кладём скрипт и ставим его в cron — например, ежедневно ночью:

#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR=/var/backups/mysql
KEEP_DAYS=14
mkdir -p "$BACKUP_DIR"

FILE="$BACKUP_DIR/mydb-$(date +%F-%H%M).sql.gz"
mysqldump --single-transaction --quick mydb | gzip > "$FILE"

# ротация: удалить дампы старше KEEP_DAYS
find "$BACKUP_DIR" -name 'mydb-*.sql.gz' -mtime +"$KEEP_DAYS" -delete
# crontab -e — каждый день в 3:30
30 3 * * * /usr/local/bin/db-backup.sh >> /var/log/db-backup.log 2>&1

Ротация: сколько поколений хранить

Хранить один последний дамп опасно: если данные испортились вчера, а вы заметили сегодня, единственный «свежий» бэкап уже содержит порчу. Поэтому держат несколько поколений — частая схема «дед-отец-сын»: ежедневные за 1-2 недели, еженедельные за пару месяцев, ежемесячные за год. В скрипте выше за ротацию отвечает find ... -mtime +N -delete.

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

Классический ориентир надёжного бэкапа: 3 копии данных, на 2 разных носителях, 1 из них — вне сервера (offsite). Бэкап, лежащий на том же диске, что и БД, не спасёт при отказе диска или компрометации сервера. Поэтому копию увозят в другое место:

# пример: синхронизация бэкапов в объектное хранилище / на другой хост
rclone copy /var/backups/mysql remote:db-backups
# или rsync на резервный сервер
rsync -az /var/backups/mysql/ backup@host:/srv/db-backups/

Восстановление — репетируйте заранее

Восстановление из логического дампа — это просто загрузка SQL обратно. Но проверять его надо до аварии, на отдельной базе/стенде:

# развернуть дамп в тестовую базу и убедиться, что всё на месте
gunzip < mydb-2026-06-18.sql.gz | mysql -u root -p mydb_restore_test

Заведите привычку: раз в период берёте свежий бэкап и поднимаете его на тестовый сервер. Если восстановление не отрепетировано — вы не знаете, есть ли у вас бэкап вообще.

Когда mysqldump уже мал

Для крупных баз (десятки-сотни ГБ) логический дамп и его восстановление становятся слишком долгими. Тогда смотрят в сторону физических бэкапов (Percona XtraBackup) и репликации/PITR (point-in-time recovery через бинлоги). Но для большинства проектов связки «mysqldump + cron + ротация + offsite + проверка» более чем достаточно.

Итог

Надёжный бэкап БД — это не одна команда, а процесс: автоматический дамп по cron, сжатие, несколько поколений с ротацией, копия вне сервера по правилу 3-2-1 и — обязательно — регулярная проверка восстановлением. Настраивается за вечер, а спасает бизнес.

Если хотите выстроить надёжную схему бэкапов и убедиться, что из них реально можно восстановиться, — помогу на консультации.

Чтобы вовремя узнавать о сорвавшемся ночном бэкапе, повесьте на задачу heartbeat-мониторинг: в self-hosted Gotcha это пара строк, и вы получите алерт, если бэкап не отметился.