/backup-job-health

name: "Backup Job Health"
description: >
  Portfolio-wide backup job health across whatever BCDR and SaaS-backup tools
  are connected: the two structurally different job models (image-based
  appliance backup vs. SaaS-data snapshot backup) and how to normalize them
  into one health record per protected unit, why a live consecutive-failure
  streak matters more than a trailing success rate, the missed-versus-failed
  distinction and its different root causes, and the two storage-trending
  risk patterns (approaching capacity, anomalous growth).
when_to_use: >-
  When assessing whether backup jobs are actually running successfully across
  a portfolio, rather than checking one client's one appliance in isolation.
  Use when: backup health, backup job failures, missed backups, backup
  success rate, failed backup jobs, backup storage trending, is this client's
  backups running, backup audit, backup job status.

Backup Job Health

Overview

"Backups are running" is the single most-assumed, least-verified fact in an MSP's environment. A backup job that failed silently three nights ago looks identical, from a distance, to one that's been succeeding for months — nobody notices until a restore is needed and there's nothing current to restore from. This skill is the recurring, portfolio-wide sweep that catches that gap before it becomes an incident: job success/ failure rate, missed-backup detection, and storage-consumption trending, rolled into one normalized view across every backup and BCDR tool an org has connected.

This skill is about whether backups are *happening*. It is deliberately narrower than disaster-recovery readiness as a whole — it does not assess whether a backup, once taken, is actually recoverable (see `restore-test-verification`), and it does not assess whether the retention window or cadence in place actually satisfies a contracted requirement (see `retention-rpo-compliance`). Treat this as the first, most frequent layer of the DR assurance stack: if jobs aren't running, nothing downstream matters yet.

Anti-triggers

• **Backup Radar's own health records** — ScalePad already aggregates and

scores backup results across vendors; use `scalepad-backup-radar` when the question is what that API returns. This skill normalizes across every connected backup tool, including orgs that have no Backup Radar at all.

• **One platform's job, alert, or storage data** — use

`datto-bcdr-api-patterns`, `datto-saas-protection-api-patterns`, `spanning-api-patterns`, or `unitrends-api-patterns` for a single vendor's request shapes and field names.

Key Concepts

Two fundamentally different job models

Backup and BCDR vendors protect data in two structurally different ways, and treating them as the same "job" concept produces misleading comparisons:

• **Image-based appliance backup** (e.g. Datto BCDR / SIRIS / Alto, Unitrends) —

protects physical or virtual servers/workstations by taking periodic block-level or image-level snapshots to a local appliance, then syncing offsite/to the cloud. A "job" here is a scheduled backup of one protected agent/asset on one appliance. Health signals include: last successful local backup, last successful offsite sync, and (for Datto BCDR specifically) screenshot/boot verification status — see `restore-test-verification`.

• **SaaS-data snapshot backup** (e.g. Datto SaaS Protection, Spanning) — protects

cloud application data (Microsoft 365 mailboxes/OneDrive/SharePoint/Teams, Google Workspace, Salesforce) by taking periodic API-level snapshots of tenant data. A "job" here is a scheduled backup pass across a set of protected seats/users for a tenant. There is no "appliance" and no local/offsite sync distinction — health signals are seat coverage (are all licensed users actually being backed up) and per-run success/failure across the tenant.

Normalize both into a single health record per protected unit (appliance-agent pair, or tenant-seat set) with the same fields — last successful run, run status, and failure streak — even though the underlying job mechanics differ. Don't force a one-size-fits-all metric like "backup window duration" that only makes sense for one model.

Job success/failure rate

For each protected unit, compute the success rate over a rolling window (default: last 30 days unless the org has a documented preference) and, more importantly, the **current consecutive-failure streak**. A unit with a 96% success rate over 30 days but a live 4-night failure streak right now is a more urgent problem than a unit with 90% success and no current streak — trailing averages hide exactly the thing that matters most: is it broken *right now*.

Missed-backup detection

A missed backup is distinct from a failed backup: a failed backup ran and errored; a missed backup never ran at all (no job execution recorded for the expected window). Both matter, but they point to different root causes — a failed job usually means an in-scope problem (disk full, credential expired, source unreachable), while a missed job often means a scheduling, licensing, or connectivity problem that's more structural (the agent/connector isn't checking in at all). Report them as separate categories rather than merging them into one "unhealthy" bucket, since the remediation path differs.

Storage-consumption trending

Track local and offsite/cloud storage consumption per appliance (or per SaaS tenant, where the vendor exposes storage/quota data) over time. Flag two distinct risk patterns:

• **Approaching capacity** — an appliance trending toward its local storage limit,

which risks retention truncation (older recovery points get purged early to make room) even while nightly jobs continue to report success. This is a silent retention risk — see `retention-rpo-compliance` for how a storage-forced retention cut interacts with a contracted retention requirement.

• **Anomalous growth** — a sudden, unexplained jump