Мониторинг резервных копий в Zabbix: схема настройки

Свежесть последней копии

Основной приём схемы — следить за временем последнего следа. Проще всего, когда задача копирования после успешного завершения оставляет файл-отметку: обновляет существующий last.txt или создаёт файл с датой в имени. У большинства программ копирования для этого есть штатная опция «выполнить команду после задачи»; одна строка — и у мониторинга появляется точка опоры.

# отметке о последней копии больше двух суток
# (item: vfs.file.time[/mnt/backup/last.txt,modify])
now()-last(/nas-backup/vfs.file.time[/mnt/backup/last.txt,modify])>172800

Порог привязывается к расписанию, а не берётся с потолка: для ежедневных копий двое суток означают «пропущено две ночи подряд» — достаточно, чтобы бить тревогу, но достаточно терпимо к одному переносу задачи на обслуживание. Для копий раз в неделю порог пропорционально больше. Если отметку поставить не получится, иногда работает дата изменения самого свежего файла каталога — но этот путь ненадёжен: программы любят трогать служебные файлы, и следом становится не копия, а мусор. Отметка от задачи честнее.

Где взять отметку в типовых схемах. Скрипт копирования на Linux после успешного прохода делает touch /mnt/backup/last.txt — одна строка в конце сценария. Большинство программ копирования имеют штатную опцию «выполнить после задачи» — туда вписывается та же команда. Для задач в планировщике Windows следом может служить запись в журнале планировщика: Zabbix читает журналы событий Windows элементом eventlog, включая прикладные каналы вроде Microsoft-Windows-TaskScheduler/Operational, — тогда триггер следит за появлением события завершения с кодом успеха. Для копий, которые уходят в облачные хранилища или в чужой сервис, приём тот же: регулярный экспорт или выгрузка оставляет локальный след — файл манифеста, отчёт, журнальную строку. Свежесть этого следа мониторится точно так же.

Хранилище копий: заполнение и рост

Третий контур наблюдения — само хранилище. Копии без вращения (когда старые вытесняются новыми) заполняют диск предсказуемо, и момент, когда места не хватает, наступает внезапно: копия не создалась целиком, потому что некуда было писать. Заполнение раздела хранилища — обычный элемент vfs.fs.size с порогом на 85–90%: раньше, чем закончится место, чтобы разобраться без спешки.

# хранилище копий занято на 90%
last(/nas-backup/vfs.fs.size[/mnt/backup,pused])>90

Рост заполнения — сам по себе индикатор здоровья: если схема предполагает ежедневные копии, график занятости ползёт вверх равномерно, а вытеснение старых делает его пилообразным. Внезапная смена формы графика — «полка» вместо роста — случай для разбора: либо копии перестали делаться, либо делаются пустыми. График не заменяет триггеры из первых двух разделов, но дешёвым элементом он отвечает на вопросы, которые те не ловят.

И практическая мелочь: на NAS или хранилище, где живут копии, нужен мониторинговый агент — Zabbix-агент, SNMP или хотя бы ping. Хранилище, с которого не снимаются метрики, делает всю схему слепой на самом важном участке.

Типовые ошибки мониторинга копий

• Верить только программе копирования. «Задача зелёная» — заявление самой программы о себе; след — заявление о результате. Мониторить стоит второе, первое — по остаточному принципу.
• Отметка на том же диске, что и копии. Это допустимо — недоступность хранилища как раз проявит себя «необновившейся» отметкой. Но тогда рядом должен жить простой элемент доступности самого хранилища: он отделяет «хранилище отвалилось» от «задача не выполнилась» без ручного разбора.
• Порог свежести без привязки к расписанию. Триггер «копии нет сутки» при еженедельном копировании будет срабатывать всегда — и приучит всех игнорировать уведомления.
• Мониторинг без проверки. Раз в несколько месяцев контур воспроизводится намеренно: отметка не обновляется, в журнал пишется ошибка — и убеждаемся, что сообщения доходят. Тот же принцип, что и для всего мониторинга: непроверенный мониторинг — гипотеза, а не контроль.
• Попытка мониторить «восстановимость». Ни след, ни журнал, ни график не отвечают, восстановится ли копия. Это отдельная процедура с отдельным расписанием — и она же закрывает вопрос честности всей схемы.

Связанные материалы

Схема копирования, которую стоит мониторить, — правило 3-2-1 и его практика в небольшом офисе — разобрана в нашей статье о правиле 3-2-1, а проверка того, что копия действительно восстановится, — в чек-листе проверки копий. Отдельная плоскость — устойчивость самих копий к целенаправленному заражению: офлайн-звено, разделение доступов и версионность собраны в чек-листе защиты копий от шифровальщиков.

Постановка копирования и мониторинга — направления резервного копирования и мониторинга и наблюдаемости.