Monitoring cPanel backups from outside the server
cPanel's built-in backup system records exactly how each run ended and which accounts it backed up, but that record stays on the server. Servatum reads it after every run, names any account that was left out, and alerts you from outside when a run fails or never happens.
What cPanel already gives you
- A log for every run. Backup logs are written to
/usr/local/cpanel/logs/cpbackup/, and each run ends with a final state such asBackup::SuccessorBackup::PartialFailure. Transfers to remote destinations are logged separately in/usr/local/cpanel/logs/cpbackup_transporter/. - Its own notification. At the end of a run, cPanel sends a notification for that final state.
- Hooks. Scripts can run before and after the whole backup run, and around each account's archive.
- An API. WHM API calls return the backup schedule and, for any backup date, which accounts have a backup.
All of it is produced and kept on the server being backed up, so it can't tell you when the server itself is the problem.
What the hooks can and can't tell you
| Hook | When it runs | What it knows |
|---|---|---|
System › Backup, post stage | After the system performs backups. Runs as root. | Nothing about the result: cPanel documents that this stage produces no output. |
PkgAcct › Create (pre, preFinalize, postFinalize) | Around each account's archive. During backups it runs as the account's own user. | That account's archive details, such as the user, whether it's incremental and the tarball path. |
Legacy postcpbackup script | Once, after everything is backed up. | Nothing about the result, and nothing per account. |
So a post-backup hook is a good trigger, but not a source of truth. cPanel's own support staff point to the backup log for the result.
Where the result actually is
| Source | What it answers |
|---|---|
Latest file in logs/cpbackup/ | Did the run finish, and with which final state? |
Latest file in logs/cpbackup_transporter/ | Did the copies reach the remote destinations? |
WHM API backup_user_list | For a given backup date, each account's status: active, inactive or no_backup. |
WHM API backup_config_get | The schedule: whether backups are enabled, which days they run, and daily, weekly and monthly retention. |
How Servatum works with cPanel
| Piece | What happens | Status |
|---|---|---|
| Trigger | The Servatum agent is registered on the System › Backup post stage, so it runs as soon as each backup run ends. | Planned for launch |
| Run result | It reads the final state from the newest backup log: Backup::Success is ok, anything else is failed. It also checks the transporter log, so a failed upload to a remote destination isn't hidden behind a successful local run. | Planned for launch |
| Missing accounts | It asks backup_user_list for that day's backup and reports every account marked no_backup by name. Other statuses are shown as cPanel reports them. | Planned for launch |
| Schedule, read not typed | It reads the schedule from backup_config_get, so Servatum knows which nights a run is due without you entering it again. If a due run never happens, the job turns missing. | Planned for launch |
| Per-client proof pages | Because results are per account, a host can give each client a proof page showing only their own account's backups. | Planned for launch |
Registering the agent uses cPanel's own hook utility:
/usr/local/cpanel/bin/manage_hooks add script /usr/local/bin/servatum-cpanel \
--category System --event Backup --stage postThe agent always exits cleanly. A problem reaching Servatum never affects cPanel's backup run.
cPanel backups or JetBackup?
Many hosts run JetBackup instead of, or next to, cPanel's own backups. They report differently, so they're separate integrations: see JetBackup monitoring. If you run both, each shows as its own job, and your proof page shows both tiers.
cPanel and WHM are trademarks of cPanel, L.L.C. Servatum is not affiliated with cPanel.
Sources
cPanel's documentation and support: