Veeam Backup & Replication

A Veeam Backup & Replication server through its REST API: jobs whose last run failed or ended with a warning, failed sessions of the last 24 hours, repositories filling up, the license, and — per protected computer or VM — its last successful backup.

Network ports to open

From the DumbMonit server (or its relay agent) to the device:

Port	Protocol	Purpose
9419	TCP	REST API (HTTPS, default)

DumbMonit logs in with a Windows account that holds only the Veeam Backup Viewer role (OAuth2 password grant on /api/oauth2/token, port 9419) and keeps the token for its fifteen-minute lifetime. Every call carries the mandatory x-api-version header, 1.1-rev0 by default: the revision that came with version 12.0.

The job states (/api/v1/jobs/states) are the one required read. The others — /api/v1/serverInfo, /api/v1/sessions (created in the last 24 hours), /api/v1/backupInfrastructure/repositories/states, /api/v1/license and /api/v1/restorePoints (every protected object’s restore points, server-wide, newest first) — are read when the role allows them. Veeam keeps some routes for the Backup Administrator role, the license among them on current versions: a refusal there is shown as “not readable”, never as an error. A server too old to know /api/v1/restorePoints — the route appeared after 12.0 — is treated the same way: no device, no error.

Validated against the vendor documentation only — not yet tested on a real system

This integration was built from Veeam’s REST API reference and help center (authentication, versioning, the job, session, repository, license and restore point models), not against a running backup server. Which routes the Viewer role may read varies with the version: tell us what your server refuses.

What it watches

All metrics are prefixed dumbmonit_veeam_.

Metric	Labels	Meaning
version_info	version	Value 1: the build, 12.3.1.1139.
job_enabled, job_running	job, type	Per job.
job_failed, job_warning	job, type	1 when the last run of an enabled job failed, or ended with a warning. A disabled job keeps its last result, which no longer says anything: it counts as neither.
job_result_info	job, type, result	Value 1: success, warning, failed, none.
job_last_run_age_seconds	job, type	Since the last run; absent for a job that never ran.
job_progress_percent	job, type	While the job runs.
jobs, jobs_failed, jobs_warning, jobs_running, jobs_disabled		Counts; at most 200 jobs are described one by one.
sessions_24h, sessions_failed_24h, sessions_warning_24h		Sessions created in the last 24 hours, by result.
repository_capacity_bytes, repository_free_bytes, repository_used_bytes, repository_used_percent	repository, type	Per repository. An object storage repository has no capacity: only its used space is published.
license_valid		1 when the license status is Valid.
license_info	status, type, edition	Value 1.
license_expiry_seconds, support_expiry_seconds		Until the license and the support contract expire; absent for a perpetual license.
license_instances_licensed, license_instances_used		Instance license use.
section_readable	section: sessions, repositories, license, restore_points	1 when the account may read it, 0 when Veeam refused.

The built-in rules that apply:

• Veeam job failed: the last run of an enabled job failed (Warning, reminded daily).
• Veeam job ended with a warning (Advisory, reminded daily).
• Veeam repository nearly full: more than 90 % for thirty minutes (Advisory).
• Veeam license expiring: less than 30 days left (Advisory, reminded daily). Only when the account can read the license.
• Client device stale: a protected computer or VM has gone past device_stale_days without a successful backup (Advisory, reminded daily); see Devices below.

Devices

Every object with at least one restore point — a VM, a physical or virtual agent-protected computer, a file share — is published under the generic family shared by every DumbMonit integration that tracks protected devices — dumbmonit_client_device_*, prefixed without veeam, documented in full under Client devices:

Metric	What	Labels
last_backup_timestamp_seconds	The object’s most recent restore point	device, type, os, user, kind
stale_seconds	Positive once an object has gone past device_stale_days (3 by default) without a new restore point; drives the Client device stale rule	device, type, os, user, kind, signal (always backup)

Limits worth knowing: a job protects its objects as a group (jobs/states gives only a count, objectsCount); the per-object date comes from /api/v1/restorePoints instead, read for the whole server in one call. Veeam creates a restore point only once a backup has at least partially succeeded, so the most recent one per object is already “the last successful backup” — nothing is filtered on the result here. Veeam does not expose a “last connection” separate from the backup itself, so last_seen_timestamp_seconds and the connection signal are never published; a device shows last_connection as ”—” on the monitor page’s table. The device’s type is Veeam’s own platform name (VSphere, WindowsPhysical, HyperV…), shown as is.

The monitor page

The Backups panel says what is wrong in a sentence, shows the failed jobs, the failed sessions of the last 24 hours, the running jobs and the license, then lists the enabled jobs — failures first — with their type and last run, and the repositories with their fill and free space. The table of protected devices (name, platform, last backup, status) follows, from the generic family above.

Give DumbMonit a Veeam Backup Viewer account

1. On the backup server, open Computer Management → Local Users and Groups → Users → New User and create the account as follows, with a long random password.

   dumbmonit

2. In the Veeam console, open the main menu > Users and Roles > Security, click Add, enter the account (for example VBR01\dumbmonit) and give it the Veeam Backup Viewer role only.

3. In DumbMonit, enter the backup server address (for example vbr.lan) and the account as HOST\dumbmonit or DOMAIN\dumbmonit, with its password.

4. Tick Accept an unverifiable certificate unless you installed your own: the REST API (port 9419) uses a self-signed one.

Required permissions

• Veeam Backup Viewer — Reads jobs, sessions, repositories and restore points

Warning

Veeam keeps some REST API routes for the Backup Administrator role, the license among them on current versions: with the Viewer role DumbMonit shows the license as not readable and never asks for more.

Vendor documentation: Requesting authorization.

Why these permissions

The local Windows account needs no other right on the machine; a domain account works too. The Viewer role is enough for the jobs, sessions, repositories and restore points DumbMonit reads.

Credentials

Credential	Fields
User name and password	The account with the Veeam Backup Viewer role, as HOST\dumbmonit or DOMAIN\dumbmonit.

Address: the host name or IP of the backup server, host:port, or a URL. Options:

• Protocol (https) and Port (9419): the REST API service’s.
• API version (1.1-rev0): sent as x-api-version. Change it only if the server refuses it; a v13 server documents 1.3-rev1.
• Accept an unverifiable certificate: the REST API’s own certificate is self-signed.
• Timeout per request (15 s).
• Device staleness (device_stale_days, 3 days by default): see Devices above.

Troubleshooting

“Veeam refused the login”: the user name needs its host or domain (VBR01\dumbmonit), or the account has no Veeam role.

“Veeam refused to list the jobs (403)”: the account has a role that cannot read jobs; give it Veeam Backup Viewer.

“Veeam refused the API version”: set the API version option to one the server lists on https://<server>:9419/swagger.

The license shows “Not readable”: expected with the Viewer role on current versions; DumbMonit does not ask for more.

No device, or the Devices panel is empty: restore_points reads “Not readable”, likely because the server is older than the route (anything before 12.0’s later revisions) rather than a role problem — restore points are ordinary inventory, not an administrator-only page.