Skip to content

Recovery Readiness

jl0906 edited this page Aug 4, 2026 · 1 revision

Recovery Readiness

Recovery Readiness evaluates more than the existence of a backup. It asks whether recovery after a complete system failure is prepared and supported by technical evidence.

Evidence levels

Level Meaning
Not recoverable No usable backup exists or a blocking condition prevents reliable evidence.
Limited A backup exists, but important protection or preparedness gaps remain.
Monitored Inventory and health are known, but complete structural verification is missing.
Structurally verified The backup was downloaded, decrypted when necessary, and read completely.
Runtime start verified The optional runner also started that exact backup in isolation.
Fully tested A successful full external test restore was documented.

The evidence level cannot be manually increased. It follows available technical and documented evidence.

Recovery Score

The score ranges from 0 to 100 and evaluates:

  • availability, age, and completeness,
  • included Home Assistant data and database,
  • structural integrity and optional database verification,
  • independent copies and multiple failure domains,
  • consistent copy sizes,
  • stable content compared with the previous complete backup,
  • emergency checklist and external dependencies,
  • successful backup protection check,
  • optional documented full restore test.

Open items include their state, deduction, and recommended next action.

Content inventory and comparison

BackupCheckup exposes only generic categories and counts: Home Assistant data, database, number of add-ons and folders, and the critical folder categories SSL, Share, and Media. Individual add-on names, arbitrary folder names, backup names, and paths are not published in Recovery entities.

The newest complete backup is compared with a previous complete baseline. Added and removed counts are shown, with special attention to disappearing critical categories. If no suitable baseline exists, comparison remains unavailable rather than making assumptions.

Storage resilience

Copies are anonymized and conservatively classified as:

  • Home Assistant device,
  • directly attached storage,
  • local network or NAS,
  • remote storage,
  • cloud,
  • unknown.

An unknown target is never assumed to be an independent failure domain.

Guided emergency checklist

These fixed items can be marked unknown, confirmed, missing, or not required:

  • backup password or Emergency Kit is retrievable,
  • access to external backup storage is documented,
  • restore procedure is known,
  • replacement hardware or installation media is available,
  • required network access is documented,
  • contacts and account ownership are documented.

BackupCheckup never stores the actual passwords, paths, notes, or contact data. Confirmations expire after 180 days and must then be reviewed again.

External dependencies

A Home Assistant backup cannot automatically include every external system. BackupCheckup supports these categories:

  • external database,
  • MQTT broker,
  • Zigbee and Z-Wave coordinators,
  • Thread or Matter infrastructure,
  • ESPHome configuration,
  • network storage or NAS,
  • reverse proxy,
  • certificates,
  • cloud services and API access.

Each category can be protected, unprotected, not applicable, or unknown. Automatically detected categories require explicit confirmation. Hostnames, addresses, and credentials are not stored.

Documented restore test

backup_checkup.record_restore_test records a restore performed outside the production system. It stores only successful or failed, full or partial scope, current backup reference, and timestamp. Free text and secrets are not accepted. Only a successful full test can produce the highest evidence level.

Local emergency plan

The panel generates an emergency plan from the current assessment and exports Markdown, HTML, or JSON. It includes procedures, evidence, risks, and preparedness states, but no passwords, tokens, backup names, paths, hostnames, or IP addresses.

Important limitation

Structural or isolated runtime verification is strong technical evidence, but it cannot guarantee external databases, radio coordinators, cloud accounts, networks, or replacement hardware. A full restore on a separate system remains the strongest test.

Clone this wiki locally