Verification & Recovery Readiness

A backup you can’t restore is worthless. The Verification tab helps you continuously validate that your backups are recoverable and measure how prepared each device is for a recovery scenario.

Note

Verification is a live agent operation. The target device must be online and connected to Breeze before an integrity check or test restore can start.

---

Verification Types

Go to Backup > Device Backup > Verification to access verification controls.

Type	Duration	What it checks	Impact
Integrity check	Fast (minutes)	Downloaded object size and SHA-256 checksum compared against the manifest, plus file counts and manifest consistency	None — no data is restored
Test restore	Medium (10+ min)	Extracts the full snapshot to a temporary location, verifies each object against the manifest, and measures restore time	Low — uses temp space, no production impact

Note

Both checks genuinely detect corruption — an object whose bytes or length no longer match the manifest fails verification (reported as Failed or Partial with the specific file listed), rather than passing on a presence check alone. Snapshots taken before checksums were recorded still verify via the size comparison.

Attested snapshots (v0.120.0+)

For a snapshot with an attestation, a v0.120.0 or later backup helper also checks the manifest itself against the attestation, and every file must match its manifest entry exactly. A snapshot that already failed its integrity check cannot be verified or test-restored: the command fails with This backup did not match its integrity record and cannot be read from storage. An unattested snapshot still verifies, with an advisory Unattested snapshot warning. See Integrity checks on restore.

Running a Verification

1. Go to Backup > Device Backup > Verification.
2. Click Run Integrity Check or Test Restore.
3. Confirm the action in the dialog.
4. The verification appears in the history table with a status of Running.
5. When complete, the status updates to Passed, Failed, or Partial.

If the device is offline, Breeze shows Device is offline. Verification requires a connected agent. and the verification buttons stay disabled. If command dispatch fails for another reason, Breeze shows the dispatch error and lets you retry after the underlying issue is fixed.

Verification History

The history table shows all past verifications with:

• Verification type
• Status (Pending, Running, Passed, Failed, Partial)
• Start time and duration
• Files verified and files failed
• Total size checked

---

Automated Verification

Breeze runs verifications automatically on a schedule:

Check	Frequency	What it does
Post-backup integrity	Every 10 minutes	Validates the most recent completed backup when the device is available
Weekly test restore	Sundays at 03:38 UTC	Runs a restore test for recent backups when the device is available
Readiness score recalculation	Daily at 02:18 UTC	Updates recovery readiness scores for all devices
Timeout detection	Every 5 minutes	Flags verifications that have been running too long

No setup is needed — automated verifications run as soon as backup is configured. If a device is offline when a scheduled verification window arrives, Breeze skips that run and logs the skip instead of creating a synthetic verification record.

---

Recovery Readiness Score

Each device gets a readiness score from 0 to 100, visible on the Verification tab:

Score	Rating	Meaning
85–100	High	Device is well-protected and verified
70–84	Acceptable	Minor gaps — review risk factors
Below 70	Low	Significant recovery risk — take action

The score is calculated from:

• Recency — how fresh the latest snapshot is (within 30 days)
• Verification success rate — recent integrity and restore test results
• RTO/RPO compliance — whether estimated recovery times meet SLA targets
• Risk factor assessment — missing backups, failed verifications, or expired snapshots

Risk Factors

The Verification tab lists specific risk factors for each device, color-coded by severity:

Risk factor	Severity	What to do
No recent backups	High (red)	Check policy assignment and agent connectivity
Verification failures	High (red)	Investigate the failed verification — storage may be unreachable
SLA breaches	Medium (orange)	Review SLA targets or increase backup frequency
Data change accumulation	Medium (orange)	Large volume of unprotected changes — run a backup
Immutable backup gaps	Low (yellow)	Consider enabling immutability on your storage configuration

Bare-metal rebuild evidence

When a device has been through a real bare-metal rebuild — from Breeze recovery media, a DR rehearsal or Restore as VM — the outcome feeds its readiness. Only settled rebuilds count: a recovery that is still running, was refused before touching a disk, or was cancelled before it started is neither proof nor failure. Breeze looks at the device’s ten most recent settled rebuilds.

• Measured recovery time. The time from the start of the restore to validation is the rebuild’s measured duration. The device’s estimated RTO becomes the slower of this and the test-restore estimate, so the SLA RTO check compares against a figure a full rebuild actually produced.
• Rebuild risk factors.

Risk factor	Severity	When it appears
Latest bare-metal rebuild failed	High (red)	The most recent settled rebuild failed. The score also drops by 10 points.
Earlier bare-metal rebuilds failed	Medium (orange)	A rebuild failed, but a later one succeeded.
Last successful rebuild is old	Medium (orange)	The last successful rebuild is more than 90 days old.
Rebuild slower than 60 minutes	Medium (orange)	The slowest recent successful rebuild exceeded 60 minutes.

A rebuild that finishes (or checks in) or fails refreshes the device’s readiness straight away; you do not have to wait for the daily recalculation. A device with no rebuild history is not penalized: rebuild evidence only adds information, it never replaces the verification-based score. If the rebuild history cannot be read when readiness is calculated, the score reflects verification only and shows a low-severity “evidence unavailable” risk factor until the next recalculation.

Note

A DR rehearsal and a Restore as VM rebuild into a disk image on a rebuild host, so they prove the snapshot can be rebuilt and how long it takes; they do not prove the physical machine’s hardware. A recovery from recovery media with the Original device identity is the production path and is only counted as successful once the restored machine has checked in.

---

Organization Backup Health

The Verification tab also shows an organization-wide health summary:

Status	Meaning
Healthy	All devices have recent, verified backups
Degraded	Some devices have low readiness scores or recent failures
Critical	Multiple devices are unprotected or have failed verifications

Use this as a quick indicator of overall backup posture.

If the overview shows No verification history, that means Breeze has no completed live verification for the device yet. Run a real verification once the device is online to populate readiness and recent-failure history.