Проверка дампа MySQL: файл есть — бэкап ещё нет

На проекте в /var/backups лежали десятки .sql.gz. Один из «свежих» не открывался: прерванный dump, диск кончился на полуслове. Ниже — минимальная проверка, которую ставят в cron сразу после бэкапа.

Серия

1. Ежедневный dump
2. Этот гайд — проверка
3. Restore

Три проверки за 30 секунд

# последний дамп (подставьте имя БД)
ls -lt /var/backups/mysql/bitrix_*.sql.gz | head -3

# 1) архив не битый
gzip -t /var/backups/mysql/bitrix_YYYYMMDD_HHMMSS.sql.gz && echo OK

# 2) не пустышка
stat -c%s /var/backups/mysql/bitrix_*.sql.gz | tail -1

# 3) маркер mysqldump в хвосте
gzip -dc /path/to/latest.sql.gz | tail -c 4096 | grep -F "Dump completed"

Готовый скрипт verify

Скачать mysql-backup-verify.sh →

sudo curl -fsSL -o /usr/local/sbin/mysql-backup-verify.sh \
  https://mediops.ru/tools/scripts/mysql-backup-verify.sh
sudo chmod 750 /usr/local/sbin/mysql-backup-verify.sh

DB_NAME=bitrix BACKUP_DIR=/var/backups/mysql \
  /usr/local/sbin/mysql-backup-verify.sh
tail -20 /var/backups/mysql/verify.log

Скрипт:

• находит последний ${DB_NAME}_*.sql.gz;
• гоняет gzip -t;
• сравнивает размер с MIN_BYTES (по умолчанию 1024);
• ищет «Dump completed» в хвосте;
• предупреждает, если дампу больше ~36 часов.

Cron: backup → сразу verify

15 3 * * * DEFAULTS_FILE=/root/.my.cnf DB_NAME=bitrix /usr/local/sbin/mysql-backup-daily.sh
20 3 * * * DB_NAME=bitrix /usr/local/sbin/mysql-backup-verify.sh

Опционально: раз в неделю restore-test

Идеал премиума: заливать дамп на отдельную тестовую БД или staging раз в неделю. Это уже следующий гайд — но без ежедневного gzip -t туда рано.

Restore по чеклисту →

Типичные сюрпризы

• Cron молчит — verify видит age > 36h.
• Диск 100% — dump оборвался, gzip -t падает.
• Другое имя файла — скрипт ищет шаблон ИМЯБД_*.sql.gz; переименуйте или поправьте маску.

Честно про Mediops

Проверку целостности дампа делаете вы на сервере. Мы покажем, если диск забит или сайт лёг — часто это следствие «бэкап забил /» или «база умерла без отката».