Мониторинг размера бэкапа в Zabbix: размер, возраст и защита от ложного OK

Проверять только факт существования файла резервной копии недостаточно. Файл может быть пустым, слишком маленьким, старым или оставшимся от предыдущего успешного запуска. Надёжнее контролировать как минимум размер и время последнего изменения, а для важных систем — ещё и результат задания резервного копирования.

Что имеет смысл контролировать

• существует ли файл или каталог бэкапа;
• каков его размер;
• когда он изменялся последний раз;
• не стал ли размер резко меньше обычного;
• появился ли новый бэкап в ожидаемое окно времени.

Размер файла через стандартный item

Для обычного файла Zabbix Agent умеет получать размер штатным ключом vfs.file.size[]. Это лучше самописного shell-скрипта: меньше зависимостей и проще переносить настройку между серверами.

vfs.file.size[/backup/site/latest.tar.zst]

Значение возвращается в байтах. В интерфейсе элемента данных удобно указать единицы измерения B, чтобы Zabbix автоматически показывал КБ, МБ и ГБ.

Проверьте возраст копии

Большой файл не означает, что резервное копирование выполнялось сегодня. Добавьте отдельный item по времени изменения файла через vfs.file.time[] и триггер, который срабатывает, когда возраст превышает допустимый интервал.

vfs.file.time[/backup/site/latest.tar.zst,modify]

Не задавайте один универсальный минимальный размер

Порог должен учитывать конкретные данные. Бэкап базы на 50 МБ может быть нормой для маленького проекта и аварией для системы, где вчера было 80 ГБ. Практичнее использовать ожидаемый минимум либо сравнивать динамику с историей и отдельно контролировать резкие отклонения.

Если бэкап состоит из каталога

Стандартный vfs.file.size[] предназначен для файла. Для каталога, набора chunk-файлов или удалённого хранилища лучше получать итоговый размер скриптом или UserParameter и возвращать в Zabbix одно числовое значение. Скрипт должен работать от непривилегированного пользователя и иметь только необходимые права чтения.

Главная проверка — восстановление

Размер и дата отвечают только на вопрос «что-то создалось». Они не доказывают, что копия пригодна для восстановления. Для критичных систем добавьте периодическую проверку архива, базы или тестовое восстановление на отдельной площадке.

Итог: хороший триггер по бэкапу складывается из нескольких сигналов: файл появился, его размер правдоподобен, он свежий, а процесс завершился без ошибки. Один зелёный item по размеру — слишком слабая гарантия.