JetBackup monitoring from outside the server
JetBackup 5 already alerts you when a backup job fails. Servatum adds the check that can't live on the same server: it expects every job on schedule, notices when one goes silent, and puts every server's results in one place, in your PRTG or Zabbix, and on a proof page your customers can see.
What JetBackup already does
Servatum doesn't replace any of this, so it's worth being clear about it first.
- Alerts at three levels. Information, warning and critical. Critical alerts cover backup, restore, download and reindex processes that failed, were aborted or never finished, and backup jobs that haven't run for a few days.
- Job Monitor per backup job. You can ask to be notified if a job produced no backups for a set number of days, or if it has been running for longer than a set number of days.
- Several delivery channels. Email, plus notification plugins for Slack, Telegram, Microsoft Teams and Syslog.
- Hooks and an API. JetBackup can run your own script before or after a task, and exposes job history through its API and the
jetbackup5apicommand.
If one server and one inbox is your whole setup, JetBackup's own alerts may be all you need.
Where on-server alerts stop
Every JetBackup alert is sent by the server it describes. That works until the problem is the server itself:
- The server is down or JetBackup isn't running. Nothing runs, so nothing reports.
- Outgoing mail is broken or the alert lands in spam. The alert exists in the panel, but nobody sees it.
- Job Monitor thresholds are counted in days. A nightly job can miss a run or two before it's flagged.
- Ten servers means ten JetBackup panels and ten sets of alerts, with no single view of what's healthy.
- Your customers can't see any of it. "We back up daily" stays a line in your terms.
In each of these cases a broken backup looks the same as a working one: silence. Servatum is built for that. It knows when each job should report, and if the report doesn't arrive, that absence is the alert.
How the integration works
The table separates what JetBackup documents from what Servatum will add.
| Piece | What happens | Status |
|---|---|---|
| Post Backup hook | After each backup job, JetBackup runs a script you choose and passes the job ID and name, the destination IDs, the start and end time in UTC, the final status code and the log ID. | JetBackup feature |
| Post Backup Account hook | After each account within a job, JetBackup passes the job ID, account ID and username, the account's result (completed, partially completed, failed or aborted) and the log ID. | JetBackup feature |
| Servatum hook script | A small script you add as the Post Backup hook. It sends the run to Servatum. Add it as a Post Backup Account hook too if you want a result per client account. | Planned for launch |
| Missed runs | If a job never starts, no hook fires. Servatum knows the job's schedule, so a report that doesn't arrive in time turns the job missing and raises an alert. | Planned for launch |
| History from the API | JetBackup's listLogs API call returns past runs, filtered by job and status. A scheduled call can backfill history when you connect, and catch anything a hook missed. | Planned |
| Backup size | The hooks don't pass the size of the backup, so size trends are not part of the JetBackup integration yet. | Not confirmed |
Status codes
The Post Backup hook reports the job result as a queue status code. Servatum will map them like this:
| JetBackup code | Meaning | In Servatum |
|---|---|---|
100 | Completed | ok |
101 | Partially completed | failed by default, with per-account results attached if you use the account hook |
102 | Failed | failed |
103 | Aborted | failed |
104 | Never finished | failed |
The hook script
This is the shape of it, using only the arguments JetBackup documents for the Post Backup hook. The released script will be open source.
#!/bin/bash
# JetBackup 5 Post Backup hook: arguments are passed in order.
JOB_ID="$1"; JOB_NAME="$2"; DESTINATIONS="$6"
STARTED="$7"; FINISHED="$8"; STATUS="$9"; LOG_ID="${10}"
# One Servatum job key per JetBackup job, kept in a local file.
KEY=$(awk -v id="$JOB_ID" '$1==id {print $2}' /etc/servatum/jetbackup.keys)
[ -n "$KEY" ] || exit 0
[ "$STATUS" = "100" ] && RESULT=ok || RESULT=failed
curl -fsS -m 10 -X POST "https://in.servatum.io/v1/jobs/$KEY/runs" \
-H 'Content-Type: application/json' \
-d "{\"status\":\"$RESULT\",
\"started_at\":\"$(date -u -d @"$STARTED" +%FT%TZ)\",
\"finished_at\":\"$(date -u -d @"$FINISHED" +%FT%TZ)\",
\"message\":\"$JOB_NAME: JetBackup status $STATUS, log $LOG_ID, destinations $DESTINATIONS\"}"
exit 0It always exits 0. JetBackup treats a non-zero exit as a failed hook, and an unreachable Servatum should never show up as a problem on your server.
In JetBackup's Hooks section you choose Create New Hook, then set the position to Post, the type to Backup, the backup jobs it applies to, and the full path to the script. The script file must be executable.
Supported setups
- JetBackup 5 on the platforms JetBackup supports: cPanel/WHM, DirectAdmin, Plesk, and Linux without a panel.
- JetBackup 4 reached end of life on 1 July 2024 and won't be supported.
- cPanel's own backups, without JetBackup, are covered separately. cPanel can run a script after its backup finishes, but doesn't tell the script whether the backup succeeded, so Servatum will read the final result from cPanel's backup log.
Nothing is installed inside JetBackup itself. The integration is one script on the server and one hook entry.
JetBackup and the Vault
The Servatum Vault is append-only: servers can write to it but never delete. JetBackup enforces retention by removing old backups from the destination, so the two need testing together before we can say they work. Until then, this page covers monitoring only.
Questions
Should I turn off JetBackup's own alerts?
No. Keep them. They catch problems on the server; Servatum catches the server going quiet.
Does Servatum see my backups?
No. The hook sends run details only: status, times, job name, log ID and destination IDs. No files and no account data.
Can my customers see their own backup status?
That's what the Post Backup Account hook is for. With per-account results, each client can get a proof page for their account, under your brand.
Is Servatum made by JetApps?
No. Servatum is independent and not affiliated with JetApps. JetBackup is their trademark.
Sources
JetBackup's documentation: