Backup and Recovery.

Before setting up backups.

Prerequisites and framing.

Know what you are protecting. Before designing a backup strategy, understand what failure modes the backups need to handle. Hardware failure on the Home Assistant host. Accidental configuration corruption. Ransomware or other malicious damage. Catastrophic site loss (fire, flood, theft). Each failure mode calls for different backup characteristics — hardware failure is handled by local backups on separate media; site loss requires offsite backups.

Consider the operation's dependencies. An agricultural operation running Home Assistant often has its operations tied to the system. An extended outage while restoring from backup affects crops, not just comfort. The acceptable recovery time shapes the backup strategy — a few hours is often acceptable for most operations; a few days is not.

Storage planning. Backups take space. A typical Home Assistant backup is a few hundred megabytes to a few gigabytes, depending on what the installation includes. Adding add-on data (InfluxDB, Frigate recordings, historical database) can make backups substantially larger. Storage for backups needs planning.

A realistic review interval. Backups that are set up once and never revisited often fail the first time they matter. A quarterly check — verify backups are running, verify they are retained, verify restore still works — is a small time investment that prevents catastrophic discovery of backup failure at the worst moment.

What a Home Assistant backup contains.

Understanding what is in the backup clarifies what is protected and what is not.

The configuration directory. All the YAML configuration files — automations, scripts, scenes, customizations, templates, integrations. This is the core of the installation's behavior.

The database. Recent entity state history (the default SQLite database, or MariaDB if configured). The history shows recent patterns; older history has typically been recorded or purged per retention settings. For operations using InfluxDB for long-term history, the SQLite/MariaDB data is less critical — InfluxDB is the archive.

User accounts and authentication data. The users, their passwords (hashed), and their permissions. A restore without this data means users have to be recreated, which is disruptive.

Add-ons and their configurations. Installed add-ons (Zigbee2MQTT, ESPHome, Frigate, InfluxDB, Grafana, Node-RED, etc.) and their configurations. The add-on installations themselves are re-fetched on restore; their configurations come from the backup.

Secrets. The `secrets.yaml` file, if used. API keys, tokens, passwords stored centrally. Protecting this file is especially important; its contents are highly sensitive.

Custom components and integrations. Community-developed integrations not part of Home Assistant core.

What is not in a standard backup. Add-on data in some cases — specifically, data that add-ons store in their own persistent volumes outside the backup scope. Frigate recordings, InfluxDB data, media files, and similar bulk data are often not captured in the standard backup and need separate backup strategies. Check each add-on's documentation for its backup behavior.

The practical implication. A Home Assistant backup restores the configuration and recent state. It does not automatically restore every piece of data associated with the installation. Operations with significant add-on data (Frigate, InfluxDB, media libraries) need additional backup for those.

Backup types in Home Assistant.

The built-in capabilities.

Full backup. Captures everything — configuration, database, users, add-ons, and their configurations. The default type. Larger than partial backups; slower to create and restore. Appropriate for comprehensive protection.

Partial backup. Captures selected components — specific folders, specific add-ons, or specific data types. Faster than full backups; smaller. Useful for targeted backups of frequently-changing configuration without re-backing-up static add-on data on every run.

Automatic backups. Home Assistant's Backup integration supports scheduled backups with configurable retention. Typically configured to run daily or weekly, keeping several recent backups before the oldest is overwritten.

Manual backups. Triggered through the UI or service calls. Appropriate before significant changes (installing a new integration, major upgrade, reconfiguration) — a backup taken just before a change provides a clean recovery point if the change does not go well.

Nabu Casa cloud backups. Home Assistant's commercial tier includes automated cloud backup as a feature. For operations that want offsite backup with minimal configuration, Nabu Casa is the easiest path. The subscription cost is modest; the offsite component handles site-loss scenarios.

The 3-2-1 backup rule.

A framework from the broader IT world that applies well here.

Three copies of the data. The original plus at least two backups. Redundancy protects against individual failures.

Two different media types. Backups on the same disk as the original do not protect against disk failure. Backups on a different physical device (external drive, NAS, cloud) provide real protection.

One copy offsite. A fire, flood, or theft that takes out the site takes out local backups too. One copy at a different physical location protects against site-loss events.

Applied to Home Assistant. The original configuration lives on the Home Assistant host. Copy two lives on a separate local device — a NAS, an external USB drive, or a separate machine. Copy three lives offsite — cloud storage, a USB drive rotated through a different location, or a second site if the operation has one.

The cost of shortcuts. A common pattern: backups stored only on the Home Assistant host. The host's disk fails; both the original and the backups go with it. Or: backups stored only on a NAS that shares the same power circuit as the Home Assistant host. A power surge takes out both. The 3-2-1 rule exists because real failures have taken out both primary and backup in these scenarios.

Local backup storage options.

Where backups live on-site.

External USB drive. The simplest option. A USB drive attached to the Home Assistant host or to another device on the network. Cheap. Works. Needs manual or scripted rotation for multiple backup versions.

NAS (network-attached storage). A dedicated device on the local network that stores files. Provides substantial capacity (terabytes), often with redundancy built in (RAID). Accessible from multiple devices. For operations with significant data to back up (Frigate recordings, InfluxDB, media), a NAS is often the practical choice.

A second computer on the local network. Backups copied to another machine via SSH, rsync, or a file share. Works without dedicated backup hardware. Limitations come from the second computer's availability and reliability.

Internal secondary drive. A second drive in the Home Assistant host, used specifically for backups. Protects against the primary drive's failure but not against events that affect both drives (power surges, physical damage, theft).

Separation principle. Whatever the local backup medium, it should be separable from the Home Assistant host in some meaningful way. A backup on the same single disk as the original does almost nothing useful. A backup on a different disk, or on a different device, starts providing real protection.

Offsite backup options.

Where backups live away from the site.

Cloud object storage. AWS S3, Backblaze B2, Wasabi, and similar services provide cloud storage at cents per gigabyte per month. Backup tools can write directly to these services. Low ongoing cost; offsite automatically. Requires internet bandwidth for uploads; full backups of multi-gigabyte installations take time to upload.

Nabu Casa's cloud backups. Integrated with Home Assistant; minimal configuration needed. For operations comfortable with a single provider relationship, this is the easiest path.

Personal cloud storage (Dropbox, Google Drive, OneDrive). Consumer services often work through Home Assistant add-ons that sync to them. Works for small backups; larger backups can run into consumer-service limits. Privacy considerations — these services have their own data-handling terms.

Self-hosted offsite. For operations with multiple sites, or a grower with a second location, a backup server at that other location provides fully-self-hosted offsite. More setup effort than cloud options; no ongoing subscription cost; maximum control over data.

USB drive rotation. A pair of USB drives, one at the site and one at a different location (home, a neighbor's shop, a safe-deposit box). Periodically swap them. Simple, no internet required, effective for operations with predictable backup rhythms.

Email or similar. Very small backups can be sent as email attachments to an offsite account. Limited to small installations; not a general solution but worth mentioning as a zero-infrastructure option.

The choice depends on the operation. Small operations with tight budgets — USB rotation or Nabu Casa cloud. Operations with infrastructure investment and technical comfort — cloud object storage with a tool like restic or borg. Operations with multiple sites — self-hosted offsite. No universal answer; match the approach to the operation.

Backup scheduling.

How often to back up.

Daily backups for active systems. Operations making regular configuration changes benefit from daily backups. The daily backup captures each day's changes. Retention of one week to one month of daily backups covers most short-term recovery needs.

Weekly backups for stable systems. Operations where the configuration rarely changes can back up weekly without much loss. Daily is still preferable — the additional storage is cheap insurance — but weekly is acceptable for stable deployments.

Pre-change backups. Always take a manual backup before significant changes. Installing a new integration, major Home Assistant upgrade, reconfiguration sweeps, add-on changes — a backup taken immediately before provides a clean recovery point.

Retention strategy. A common pattern: keep daily backups for two weeks, weekly backups for two months, monthly backups for one year. This gives multiple points of recovery across different time horizons. The exact retention depends on the operation's recovery needs and storage capacity.

Automated rotation. Home Assistant's Backup integration supports automatic deletion of old backups. Configure the retention, and old backups delete automatically as new ones arrive. Manual cleanup of old backups is a recipe for eventual storage exhaustion.

Testing restore.

The backup that has never been restored is a backup that might not restore.

Why testing matters. Backups fail. Storage media fails. Backup configurations get broken by software updates. Credentials for cloud backup services expire. Retention policies accidentally delete the backups that would have been useful. All of these fail silently — the backup appears to be running fine until it is needed, at which point it does not work.

How to test. Periodically — quarterly is reasonable — restore a backup to a test environment. A second Home Assistant instance (on spare hardware, in a VM, or as a temporary container) receives the restored backup. Verify the restored installation runs, that automations fire, that dashboards work, that integrations reconnect.

Testing without a spare system. A Home Assistant VM or container on the grower's laptop can receive a restore for testing purposes. The restored instance does not need to be production-capable; it needs to demonstrate that the backup actually contains what it should and can be restored.

What to verify in a test restore.

- The restore process itself completed without error. - The restored installation starts up and reaches a running state. - Configuration (automations, scripts, dashboards) is present. - Integrations reconnect (they may need credentials re-entered, but the integration definitions should exist). - Recent history is present (to the extent the backup included it). - Add-ons that were installed at backup time are installed in the restore.

The failure mode without testing. An operation's Home Assistant host dies. The grower reaches for the backup; something is wrong; the backup will not restore, or restores incompletely. Now the operation is in emergency mode, trying to fix both the production loss and the backup system, under pressure. A quarterly test would have revealed the problem before the pressure.

Restoring from backup.

The process that matters on the day it matters.

The typical restore scenario. The original Home Assistant host failed or needs to be rebuilt. A new host (or the same hardware after repair) runs Home Assistant fresh; the backup is uploaded or attached; the restore process applies the backup's contents.

Preparation. Before restoring, have access to the backup file, the credentials for any integrations (even though the backup includes configuration, some integrations need to re-authenticate), and enough time for the restore to complete.

The restore process for Home Assistant OS / Supervised. Settings → System → Backups, upload or select the backup, click restore. The system applies the backup and restarts. For a full backup, this typically takes several minutes to an hour depending on the backup size and the host.

The restore process for Container deployments. Restore involves placing the backed-up configuration directory in place and ensuring the Home Assistant container picks up the restored data. Slightly more manual than the OS / Supervised case.

Add-on data restoration. Standard Home Assistant backups include add-on configurations but may not include all add-on data (particularly bulk data like recordings or databases). Verify what was included in the backup; restore add-on-specific data from separate backups where needed.

Integration re-authentication. Some integrations require re-entering credentials after restore. API tokens may have been invalidated; OAuth flows may need to be redone. Budget time for this in the restore process.

Device re-pairing. For some integrations (Zigbee, Z-Wave), the device pairings may or may not survive the restore depending on the integration and the backup. Zigbee2MQTT typically survives; ZHA's survival depends on the specific configuration. Test in advance.

Add-on and service backups.

Home Assistant's standard backup may not cover everything.

InfluxDB. InfluxDB's data volume is separate from Home Assistant's backup in most configurations. Back up InfluxDB data separately — either through InfluxDB's own backup commands or by snapshotting the underlying volume.

Grafana. Grafana's data volume includes dashboard definitions and settings. Back up the volume; additionally, export dashboards to JSON files and keep them in Git for extra durability.

Frigate. Frigate's recordings are substantial and typically not in the Home Assistant backup. For critical recordings (security events, compliance documentation), back up the recordings to a separate location. Routine recording that does not need long-term preservation can rely on local storage and shorter retention.

ESPHome. ESPHome's add-on data includes the device configurations. Standard backup captures this. The device firmware is regenerated from configuration; the configuration is what needs to be backed up.

Node-RED. Flow data is in the add-on's data volume. Standard backup typically captures this. Verify.

Zigbee2MQTT. The configuration and device database are in the add-on's data. Standard backup captures this for the add-on; the backup includes enough to rebuild the Zigbee mesh after restore.

Mosquitto. MQTT broker configuration. Standard backup captures this.

Graybox pattern. For operations running multiple services on the same host (the graybox approach), each service has its own data to back up. Understanding what each service stores and whether the standard backup captures it matters.

Security for backups.

Backups contain sensitive data.

Encryption. Backup files contain passwords (hashed but still valuable to attackers), API keys in secrets.yaml, and the configuration that reveals how the operation works. Encryption of backups at rest protects against unauthorized access. Home Assistant's backup system supports encryption; enable it for backups stored outside controlled environments (cloud storage, USB drives that travel).

Transport security. Backups moving over the network (uploading to cloud, copying to NAS) should travel over encrypted connections. HTTPS for cloud uploads, SSH or SMB-with-encryption for local network transfers. Transport encryption prevents interception during transfer.

Access control. Who can access backup files matters. A backup file on a shared network drive accessible to every user is a security issue. Backups should have access restricted to accounts that legitimately need them.

Key management. Backup encryption introduces key management. A strong password for backup encryption is necessary; losing the password means losing access to the backup. Store the password in a password manager or safe; backup-password loss at the moment of needing to restore is a self-inflicted catastrophe.

Ransomware considerations. Ransomware attackers specifically target backups. Backup servers accessible from compromised systems are backups that can be deleted or encrypted along with the original. Immutable backups — stored on write-once media, or on services that support retention locks — resist this attack. For operations at meaningful risk, consider immutable offsite backups.

Verification and monitoring.

Backups need visibility.

Success monitoring. Every scheduled backup should be verified as having completed. An automation that checks for a recent backup file and alerts if none has appeared in the expected window catches backup failures early. "No backup in two days" is better to know within two days than when the restore is needed.

Integrity verification. Beyond existing, backups should be verifiable. Checksums of backup files catch corruption. Tools that test the backup file structure (opening it and listing contents) verify more than mere existence. For critical backups, periodic deep verification — actually restoring to a test system — is the most thorough check.

Size trends. A backup whose size has dropped dramatically from its recent baseline is suspicious. Either data was lost before the backup or the backup is capturing less than before. Monitoring backup size over time surfaces this kind of silent failure.

Offsite sync confirmation. Cloud backups complete successfully locally but fail to upload. Or upload successfully but are not retained. Verifying the offsite copy is accessible — periodically downloading to confirm — closes the loop.

Common failure modes.

Specific backup and recovery problems from real deployments.

The backup that nobody tested until it was needed. The host died. The grower retrieved the backup; the restore failed due to a corrupted backup file. Months of data and configuration were lost. Fix: quarterly restore tests would have caught the corruption when it was inconvenient to investigate rather than catastrophic to miss.

The backup stored only on the original host. Disk failure took both the running installation and the backups on the same disk. Fix: 3-2-1 rule; backups must be on separable media from the original.

The offsite backup that expired. Cloud backup credentials expired; backups stopped uploading; nobody noticed. Six months later, the offsite backup showed six-month-old data. Fix: monitor the offsite backup, verify recency regularly, alert on missing backups.

The backup that used the default retention and deleted the wrong thing. Automatic retention deleted older backups as newer ones arrived. The configuration issue being investigated was in a backup from three months ago; that backup had been rotated out. Fix: retention policies that keep longer-term monthly backups alongside the daily/weekly rotation.

The restore that silently skipped add-on data. The restore completed; the grower assumed everything was back; later discovered that Frigate's recordings and InfluxDB's history were gone (not backed up by the standard Home Assistant backup). Fix: understand what the standard backup covers; add separate backup for bulk add-on data that matters.

The backup encryption password that was lost. The backup was encrypted for security; the password was in the head of the grower who had to step away from the operation; no one else had it. The backups were unrestorable. Fix: document backup encryption passwords in a secure, accessible-to-authorized-people location; password manager entries shared with the appropriate people.

The backup that was too large to practically upload. A multi-gigabyte backup took 12 hours to upload over rural internet. During those 12 hours, no new backups completed. Fix: smaller partial backups for frequent uploads; full backups at a cadence that matches upload capability; consider local offsite options where bandwidth is limited.

The backup that captured corruption. The configuration had a silent bug; the backup captured the bug. Restoring from backup restored the bug. Fix: test-restore new backups periodically to catch corruption before propagating; version-control configuration separately so known-good states are available independent of backups.

The NAS that hosted backups and was also compromised. Ransomware affected both the Home Assistant host and the NAS where backups were stored. No clean backup remained. Fix: offsite backup that is not network-accessible from the compromised systems; immutable backup services; rotated USB drives kept physically separate.

The Zigbee/Z-Wave mesh that did not restore. The restored Home Assistant had the integration but no device pairings. Every Zigbee device had to be re-paired. Several days of effort on a large installation. Fix: know in advance whether your integration backs up device pairings; for ZHA specifically, ensure the coordinator's data is included; for Zigbee2MQTT, it typically is.

What not to do.

Patterns to avoid.

Don't rely on a single backup copy. Redundancy is the point. One backup is almost-no-backup when the single copy fails.

Don't store backups only where the original is. Same disk, same machine, same site — none of these protect against the failures most likely to matter.

Don't skip testing. Untested backups fail. The test is cheap; the untested backup failure is expensive.

Don't hide backup passwords in one person's head. Keys lost at the moment of needing to restore are catastrophes that are entirely avoidable with sensible key management.

Don't ignore what is not in the standard backup. Add-on bulk data (Frigate recordings, InfluxDB history), media libraries, and similar often need separate backup strategies. Assume nothing; verify what each backup actually includes.

Don't forget about network dependencies during restore. A restore that requires pulling add-on images from the internet fails if the internet is down at restore time. For operations with unreliable connectivity, consider local mirrors or offline-capable restore procedures.

Don't run backups only on a schedule and never manually. A backup immediately before a significant change provides a recovery point for that change. Relying only on scheduled backups leaves gaps that matter.

Don't let the backup system decay. Backup configurations need maintenance. Credentials expire; storage fills up; retention policies drift. A "set and forget" backup is a backup that decays silently.