Fix the Zabbix template's alerting and bring it to Zabbix 7.4

[cfoellmann]

Tiered "No backups detected" triggers could never fire

Each of the 3, 4 and 5 day expressions additionally required fuzzytime(...,172800s)<>0 — "the backup is younger than 2 days" — while at the same time demanding it be older than 3, 4 or 5 days. That is a contradiction, so none of them could ever fire.

Worse, the 2 day trigger required the backup to be younger than 3 days, so once a job had been failing for three days its alarm resolved itself and the template went quiet exactly when it mattered most.

Each tier now checks only its own lower bound and the next tier's, and the 5 day tier has no upper bound:

2 days:  fuzzytime(...,172800s)=0 and fuzzytime(...,259200s)<>0
3 days:  fuzzytime(...,259200s)=0 and fuzzytime(...,345600s)<>0
4 days:  fuzzytime(...,345600s)=0 and fuzzytime(...,432000s)<>0
5 days:  fuzzytime(...,432000s)=0

The 5 day boundary was also written as 432800s (5.009 days) instead of 432000s.

"Backup 20% Smaller in Size" compared against 80%

last(size)/last(size,#2)<0.2 fires when a backup shrank to under a fifth — 80% smaller, not the 20% the name promises. A backup could lose three quarters of its content without a word. It now compares against 0.8, and both ratio triggers require a non zero previous value so they no longer end up unsupported after a zero sized backup.

Added: "No statistics received"

A nodata() trigger driven by a new {$DBBACKUP.NODATA.PERIOD} macro (default 2d). The age based triggers work off the last reported backup timestamp; this one fires when a job stops reporting to Zabbix altogether.

Housekeeping

• export version raised to 7.4
• units: B on the backup size item, so the frontend stops showing raw byte counts
• template description points at this repository instead of the tiredofit one
• item tags deliberately left on the existing Application convention, so saved filters keep working

All UUIDs are unchanged, so a re-import updates the existing objects in place rather than creating duplicates.

Testing

Verified against a live Zabbix 7.4.14 instance: configuration.import returns true, and the API reads back all 9 trigger prototypes with their expressions parsed, the macro resolving in the nodata expression, and the new units.

The tier coverage was additionally simulated across backup ages from 0 to 10 days — exactly one trigger is active at every age from 2 days on, with no gaps and no overlaps.

Out of scope, but worth knowing

While testing I confirmed a separate problem in the sender, which this PR does not address. dbbackup_post_dbbackup sends an LLD payload containing only its own job:

zabbix_sender ... -k dbbackup.backup -o '[{"{#NAME}":"'${backup_job_db_host}.${backup_job_db_name}'"}]'

Zabbix treats every LLD receipt as the complete list. With two jobs in one container I measured, on Zabbix 7.4.14, that each send immediately disables the other job's items — enabled_lifetime_type=2 is the default — together with all nine of its triggers, and schedules them for deletion after lifetime=7d. The jobs take turns silencing each other's alerting entirely. Sending both names in one payload restores them.

Related: {#NAME} uses ${backup_job_db_name}, which is never reassigned inside the per-database loops, so a job with DB_NAME=ALL collapses every database into one item set.

Happy to open a separate PR for either if you have a preference on the approach — both change {#NAME}, which orphans existing history, so it seemed worth asking first.

Note

This branch is independent of my two other PRs. It adds a 4.9.3 CHANGELOG heading, as does #493 — whichever merges second will need a trivial conflict resolution at the top of the file.