Skip to content

8 Home Assistant Backup & Disaster Recovery Questions

Backup and recovery usually fails not with "no backup" but with "a backup you cannot restore from" — the restore comes up missing a piece, the Add-on data is gone, or you have never actually restored once and discover the snapshot is broken only when it matters. These eight questions go in order: pick a shape, back up, go offsite, rehearse, roll back, version, and recover from disasters. Each has commands you can use today.

Full steps are in the backup and restore guide; upgrade rollback is in HA OS upgrade and rollback.

1. Which backup shape, and how to choose

Shape When How
HA OS snapshot Box or VM running HA OS Supervisor built-in, one click in UI
Docker volume Docker install inside an existing Linux Manage /config and Add-on volumes yourself
Hypervisor snapshot HA as a VM on PVE/ESXi Snapshot at the host layer, whole-machine revert

Rule: pick by install shape. HA OS snapshots are easiest; Docker needs manual volume care; VMs lean on host snapshots.

2. Snapshots must include Add-on data

This is the most common restore failure. A default snapshot may skip Add-on data, so after restore the Mosquitto accounts and Node-RED flows are simply gone.

# In Settings, System, Backups, when creating manually, tick:
# [x] Include Add-on data
# Confirm automatic snapshots also enable this

Rule: no Add-on data tick = pointless restore. Confirm it on every snapshot.

3. Backup frequency and retention

  • Daily automatic: HA OS Supervisor scheduled snapshots for daily cover.
  • Manual full before upgrades: take one before big changes, note the version.
  • Retention: 7 to 30 days rolling daily; keep a dated archive at key moments (upgrades, big edits).

Rule: automatic for daily, manual for milestones, rolling retention so old snapshots do not expire silently.

4. How to land an offsite copy

Local backups do not survive a burned machine. Pick one or stack them:

# Sync /config to a NAS over SSH, incrementally
rsync -a --delete /opt/ha/config/ nas:/backup/ha/config/

# Or sync the whole snapshot directory
rsync -a /opt/ha/backups/ nas:/backup/ha/snapshots/

Encrypted cloud upload works too, but never send token-bearing files in plaintext.

Rule: the offsite copy is real DR. rsync to a NAS, another machine, or encrypted cloud, at least one.

5. You must actually rehearse the restore

Do not attempt your first restore during an incident. Periodically take a snapshot and really restore it on a test box or spare machine, then verify: config complete, Add-on data present, automations run. Most "restore failed" cases are discovered only on the first real attempt.

Rule: a restore drill matters as much as the backup. Rehearse quarterly so you trust the snapshot.

6. Back up before upgrade, and know the rollback path

Major releases ship the first Wednesday monthly. Before upgrading:

  1. Manual full snapshot, Add-on data included.
  2. After upgrade, open Settings, System, Repairs and follow the guide for deprecated config.
  3. If an automation will not run, open its Trace to find the break.
  4. If unfixable, one-click roll back to the pre-upgrade snapshot in Supervisor.

Full steps in HA OS upgrade and rollback.

Rule: backing up before upgrade is non-negotiable; confirm the rollback path in advance, do not hunt for it under pressure.

7. Config as code, in git

Version the text-based config; it is finer-grained than snapshots alone:

# Commit only config, never secrets.yaml (it holds tokens)
git add configuration.yaml automations.yaml scripts.yaml
git commit -m "add guest mode automation"

A mistaken delete or edit can be git diff-ed back to any version.

Rule: put configuration.yaml and friends in git, exclude secrets. Mistakes become reversible, more precisely than with snapshots.

8. What saves each disaster scenario

Scenario Fix
Dead SD card Swap to NVMe/SSD, restore latest snapshot with Add-on data
Burned machine Offsite copy + fresh HA OS on new hardware, restore snapshot
Deleted config git revert to last version, or restore single file from snapshot
Broken upgrade Supervisor rollback to pre-upgrade snapshot

Rule: three copies (local snapshot, offsite, git) map to three disasters; miss one and one scenario is unrecoverable.

Why a snapshot feels safe but often is not

Plenty of people set up automatic snapshots and never look again, until a real incident reveals three silent failures: the snapshot wrote only half because the disk was full, the Add-on data box was left unticked so the restore came up missing pieces, or the scheduled job quietly failed one day and nobody noticed. So "having a snapshot" and "being able to restore" are separated by one real restore drill. The next few sections cover each install shape and the restore steps in full, so the backup in your hand actually holds up when it matters.

How to verify a backup without a full restore

A full drill is the gold standard, but you can catch the two most common faults without rebuilding a machine. First, watch the snapshot file size over time: a sudden drop usually means the disk filled or the job half-wrote, and a half-written snapshot restores into nothing. Second, peek inside the snapshot archive and confirm the Add-on folder is present and non-empty — that is the piece most often silently omitted, and the one that makes a restore look successful while missing Mosquitto or Node-RED. Neither replaces a real drill, but both turn "I assume it works" into "I checked the two things that break most often".

Also watch retention: keeping only the last three daily snapshots means a corrupted config can overwrite all of them before you notice, so keep at least one weekly or monthly archive that the daily rotation cannot touch, and confirm the offsite copy is actually newer than the local one before you trust it. A backup you never verified, and a copy that silently stopped updating, are the two ways "disaster-ready" turns out to be an illusion.

A retention policy that actually protects you

A reasonable baseline: keep 7 daily snapshots for recent mistakes, 4 weekly for the slower-moving config drift, and at least 2 monthly archives that the daily and weekly rotation never overwrite. Tie the monthly archive to a real event — the day after a major upgrade, or the first of each month — so you always have a known-good point to fall back to. Pair that with one offsite copy and one git history of the text config, and you have three independent recovery paths that cover the usual failure shapes: a bad edit, a failed upgrade, a dead disk, and a burned machine.

Docker: how to back up the volume yourself

If you are not on HA OS and run Docker yourself, Supervisor snapshots are unavailable, so you must manage the volume:

# Stop the container, then archive /config and the Add-on volume
docker stop homeassistant
tar -czf /backup/ha-config-$(date +%F).tar.gz /opt/ha/config
docker start homeassistant

# Or rsync the volume directly out
rsync -a /var/lib/docker/volumes/ha_config/_data/ nas:/backup/ha/config/

Rule: the Docker build has no "one-click snapshot". The volume must be backed up by hand, or config and Add-on data vanish together with no restore path.

A real restore drill, step by step

Do not only imagine that you can restore. Take a snapshot and walk through it on a spare machine:

  1. Install the same HA OS version (or start the same container image).
  2. Upload the snapshot, open Settings → System → Backups → Restore, and tick "include Add-on data".
  3. After restore, check three things: are the Mosquitto accounts present, are the Node-RED flows present, do the automations run.
  4. If any are missing, the snapshot is incomplete — go fix the backup strategy now, not during a real incident.

Automated offsite via cron

# Every day at 3am, rsync the snapshot directory to a NAS; ping a webhook on success or failure
0 3 * * * rsync -a /opt/ha/backups/ nas:/backup/ha/snapshots/ \
  && curl -s "https://ha.local/api/webhook/backup_ok" \
  || curl -s "https://ha.local/api/webhook/backup_fail"

Watch the webhook result; a failed nightly sync that nobody sees is the same as no offsite copy at all.

Rule: automated offsite plus a periodic real restore, both present. Without both, "disaster-ready" is self-comfort, not a fact.

The 8-point pre-flight checklist

  1. Pick backup shape by install (Q1).
  2. Tick Add-on data on snapshots (Q2).
  3. Daily automatic plus manual pre-upgrade full, rolling retention (Q3).
  4. At least one rsync offsite copy (Q4).
  5. Rehearse a real restore quarterly (Q5).
  6. Back up before upgrades and confirm rollback (Q6).
  7. Put config in git, exclude secrets (Q7).
  8. Three copies cover SD death, burn, and deletes (Q8).

Bottom line: backup is not the finish line, restore is. Tick the snapshot fully, keep one offsite, rehearse for real, and version the config. With those four done, HA is actually disaster-ready.