Короткий ответ

ICMP до WS-042 и зелёный агент не значат, что ночной backup успешен. В Zabbix нужны минимум два сигнала: результат job (Success/Failed из Veeam/PBS/скрипта) и возраст артефакта (mtime файла/ succeess-маркера не старше RPO). Не мониторьте только «процесс backup.exe запущен». Не подменяйте контроль restore. Доступность хоста: ICMP/сервис. Карта: backup FAILURE не должен тонуть в CPU Warning.

Сервер zabbix.example (10.0.20.50). Маркер-пример: \\backup.zabbix.example\Repo01\WS-042.ok или /backup/WS-042/latest.ok.

Симптомы и как отличить

Типичная картина:

  • Veeam красный, Problems пуст;
  • файл копии от прошлого месяца, триггеров нет;
  • item proc.num[veeam] = 1 днём — ложный покой;
  • nodata на trapper, потому что sender не вызывается из job.

Отличия:

ЕстьНетВывод
Ping VMконтроль jobэтот материал
Алерт RAIDbackupRAID
Алерт диска Repoвозраст конкретной VMдополнить item на маркер

Возможные причины

  1. Никто не ставил item — «бэкап же сам шлёт почту».
  2. Парсят лог «started», не «Success».
  3. Смотрят размер шары, не mtime экземпляра.
  4. Trapper без zabbix_sender в post-job.
  5. Маркер пишется даже при Failed (скрипт exit 0).
  6. Timezone: файл «сегодня» по UTC, RPO считали локально.
  7. Редко: immutable repo недоступен агенту — item unsupported, алерт на unsupported выключен.

Диагностика

1. Что есть в Zabbix сейчас

Latest data хоста backup-сервера и WS-042: есть ли ключи job, trapper, vfs.file.time. Если пусто — вы ничего не контролируете, дальше архитектура item, не «порог».

2. Возраст файла (если агент видит repo)

Linux:

zabbix_get -s 10.0.20.42 -p 10050 -k 'vfs.file.time[/backup/WS-042/latest.ok,modify]' \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk

Значение — unix mtime. Триггер: now() - last(...) > {$RPO.SECONDS}.

Windows агент на backup server:

& 'C:\Program Files\Zabbix Agent 2\zabbix_agent2.exe' -t 'vfs.file.time[D:\Repo01\WS-042.ok,modify]'

Нет доступа к пути — item будет unsupported. Права пользователя службы агента, не ваши в RDP.

3. Результат job

Предпочтительно: штатный trapper из документации Veeam/скрипта:

zabbix_sender -z 10.0.20.50 -s 'VBR01' -k 'backup.job.result[Daily-VMs]' -o 0

0 = fail, 1 = success — зафиксируйте в шаблоне и не меняйте смысл. Проверка, что trapper доходит: Latest data после ручного sender (окно теста).

4. Ложные источники

proc.num, ICMP, «диск Repo не 100%» — недостаточны. Диск может быть полон старыми копиями при failed новых.

Решение

Сценарий A. Маркер Success в конце job

Job пишет WS-042.ok только после проверки exit code 0 / Result Success. Zabbix: vfs.file.time + nodata на trapper как второй сигнал.

# возраст маркера больше 26h при суточном job (запас на окно)
(now()-last(/VBR01/vfs.file.time[/backup/WS-042/latest.ok,modify]))>93600

Подгоните 26h под расписание, не 24h ровно — иначе флапы.

Сценарий B. Trapper + nodata

Item trapper backup.job.result[Daily-VMs]. Триггер last()=0 (failed) и nodata(...,28h)=1 (скрипт не стрельнул). Оба нужны: failed пришедший vs тишина.

Firewall: zabbix_sender на 10.0.20.50:10051, не 10050.

Сценарий C. Парсинг лога

log[/var/log/backup/job.log,ERROR] как доп. сигнал, не единственный. Ротация логов обнуляет. Маркер надёжнее.

Сценарий D. Нет доступа агента к repo

Не share на весь мир. Агент на самом backup-сервере, PSK свой. Либо sender с job-хоста.

Сценарий E. Карта алертов

Severity High/Disaster на fail backup. Не Warning как CPU. Зависимость: если repo host down — один корневой PROBLEM, но не глушите backup-fail, если repo жив а job красный.

Как проверить, что проблема устранена

  1. Ручной zabbix_sender fail → PROBLEM.
  2. Sender success → OK.
  3. Переименуйте маркер на стенде / задержите job → PROBLEM по возрасту до наступления пользовательского «данных нет».
  4. Не трогайте боевой backup ради теста без окна.

Прогон реального job в ближайшее расписание: Latest data обновился, Events без ложного nodata.

Если не помогло

  • Sender ходит на старый IP Zabbix.
  • Host name в sender ≠ UI (VBR01 vs vbr01).
  • Агент не читает DFS path, только локальный диск.
  • RPO 15 мин, а item interval 1h — несопоставимо. Интервал item << RPO.

Профилактика

  • Любой новый job: два item в том же change.
  • Макрос {$RPO.SECONDS} на хосте.
  • Алерт unsupported на backup-item.
  • Раз в квартал сверка: список job в Veeam vs список item в Zabbix.

RPO живёт в макросе хоста, не в голове дежурного. Суточный job: возраст маркера больше 26–28 часов. Часовой: больше 90–120 минут. Интервал item заметно короче RPO, иначе клиент узнает первым. Trapper с нулём (job failed) и nodata (скрипт не вызвался) — разные тикеты: упало задание против умерла интеграция с 10.0.20.50:10051.

Не мониторьте только Veeam. Windows Server Backup, dump PostgreSQL, PBS, borg — тот же шаблон двух сигналов. Иначе фраза «у нас Zabbix зелёный» означает ping VM.

Права на маркер: служба Zabbix Agent 2 это не ваш интерактивный админ. NTFS на D:\Repo01 проверьте для учётки службы. Unsupported на vfs.file.time без алерта на unsupported — такое же слепое пятно, как отсутствие item.

Сверьте список job в backup-ПО со списком trapper/маркеров в Latest data на zabbix.example. Расхождение «в Veeam 40 job, в Zabbix 12» — дыра. Новый job без двух сигналов не выпускайте в прод. RPO макроса и расписание job должны совпадать с точностью окна, не «примерно сутки».

FAQ

Достаточно ли письма от Veeam?

Нет как единственный канал: почта фильтруется, человек в отпуске. Zabbix — дежурство.

Мониторить размер копии?

Как доп. (резко 0 байт). Возраст и статус важнее размера.

PBS / dump / Windows Server Backup — тот же принцип?

Да: exit code + артефакт + nodata. Другой лог, те же два факта.

Можно ли system.run['veeam job'] из Zabbix?

Не замена планировщика. Remote exec ради статуса — лишний риск. Trapper из самого job.

Хост WS-042 выключен по ночам

Job должен отражать это (exclude). Иначе вечный fail. Maintenance не заменяет exclude в backup-ПО.

Restore не мониторим?

Факт restore-теста — отдельный процесс. Здесь — «копия есть и свежая». Не путайте RPO и «мы когда-то восстанавливали».