Pillar for Veeam.

Everything Veeam knows about your backups, read by service.

Request early access

APIs

What Pillar reads from Veeam.

Read-only, over the Veeam Backup & Replication REST API.

Backup jobs
Which machines are in each job, its schedule and its backup window.
Retention
Restore points or days kept, and the GFS weekly, monthly and yearly points.
Restore points
Every point for every machine, and how far back the chain goes.
Backup infrastructure
Repositories and their capacity, immutability settings, proxies and managed servers.
Replicas and failover
Replica machines, their restore points and their failover state.
Sessions
Every job run: result, duration, warnings, and the last time each machine was backed up.

Together

Veeam and Pillar: a perfect pair.

Veeam knows what was backed up. Pillar knows which service it serves. Each gives the other what it cannot see alone.

Veeam

What Pillar inherits from Veeam.

Backup jobs: which machines, and when they run.
Retention: how far back each machine can go.
Recovery objectives already set as policy: RPO and RTO.
Machines and counts, including the ones in no job.
Session results: succeeded, warned or failed.
Backup infrastructure: repositories, capacity, immutability.
SureBackup verification outcomes.

Pillar

What Pillar gives Veeam.

Service awareness: every job tied to its service.
Business context: owner, department, criticality.
Application groups with a proposed boot order.
Agentless, credentialed discovery of dependencies.
Recovery commitments checked continuously.
Evidence mapped to SOX, GDPR, DORA, HIPAA, ISO 22301.
Answers for the auditor, the CFO and the HR lead.

Veeam

Maximizing your Veeam experience.

3 specific ways adding Pillar into your Veeam process increases your resilience posture.

SureBackup
Veeam boots backups in an isolated lab and verifies them. Pillar makes that verification mean something to the business.
Veeam inherits the application group as an artifact, so verification runs against a real business definition, and Pillar keeps that definition current through change.
A passing verification becomes an attribute of the service, “Payroll verified this morning”, not a job that went green.
Services with no verification job, or whose last verification is older than their objective allows, are shown as the gap they are.
The outcome lands in the service’s evidence record, against the framework that asks for it.
Veeam ONE
Veeam ONE watches jobs, infrastructure and RPO. Pillar reads it by service.
Each alarm is routed to the service it touches, so a failure reads as “HR Portal” rather than a job number.
Alarms are ranked by the recovery commitment the service carries, not by volume, so when everything is called critical you still know what comes first.
RPO reporting becomes a per-service view: which services sit inside their objective right now.
Every finding carries the owner and the department, so the right person hears about it.
Veeam Recovery Orchestrator
Recovery Orchestrator runs the plan. Pillar keeps the plan true to the estate.
The plan’s scope and order are proposed from discovered dependencies, for a person to accept in Orchestrator.
The plan’s RTO and RPO targets become the service’s recovery commitment, checked against the estate between plan runs.
Drift surfaces as a change to the service: a new component, a machine that left a job, an account switched off, before the next readiness check finds it.
Readiness-check results and plan documentation are carried into the evidence record.