Backing Up Home Assistant So a Dead SD Card Isn't Fatal

Home Assistant setups have a way of quietly becoming irreplaceable. You start with a couple of automations, and eighteen months later you’ve got fifty entities, a dozen carefully tuned automations, a Zigbee network with thirty devices paired to a specific coordinator, custom dashboards nobody could reconstruct from memory, and integrations held together with credentials you set once and forgot. All of it lives on a single SD card in a Raspberry Pi, and SD cards do one thing reliably: they die. Usually without warning, usually taking everything with them, and — this is the part that stings — usually at the exact moment you least want to spend a weekend rebuilding.

The good news is that Home Assistant has genuinely excellent built-in backups, and setting up automated, encrypted, off-box backups takes about five minutes. The bad news is that most people either never turn it on, or turn on backups that quietly write to the very SD card that’s about to fail. Let me explain what a good backup actually needs to survive, because the “why” here dictates every decision about the “how”.

Why SD cards specifically, and why local backups aren’t enough

SD cards wear out because flash memory has a finite number of write cycles per cell, and Home Assistant writes constantly — its recorder database logs every state change of every entity, several times a second across a busy house. That workload is close to the worst case for cheap flash. A card that would last years in a camera can die in months under Home Assistant, and the failure mode is often silent corruption rather than a clean stop, so you may be running on a dying card without knowing it.

This is why a backup living on the same card is worthless for the disaster it’s meant to cover. When the card fails, the backup fails with it. A real backup has to leave the machine entirely — onto a NAS, a cloud object store, another server, anywhere that isn’t the thing that’s about to break. The single most important property of a backup is that it survives the failure of the original, and a local-only backup fails that test on the one occasion it matters.

The second property that matters is that you can actually restore from it. A backup you’ve never tested is only a hypothesis about recovery. I’ll come back to this because it’s the step everyone skips and the one that turns a “quick restore” into a very bad Sunday.

What Home Assistant backs up, and what it doesn’t

A Home Assistant backup is a tar archive containing your configuration, your database (optionally), your add-ons and their data, and the secrets and credentials that make integrations work. A full backup is a complete snapshot you can restore onto fresh hardware and be running again in minutes. That’s the promise, and it mostly holds — with two caveats worth knowing.

First, the recorder database can be huge, and including it in every backup makes the archives enormous and slow. For most people the config, automations, and add-on data are the irreplaceable parts; the history is nice to keep but not worth bloating every backup. You can exclude the database from routine backups and keep it in occasional full ones.

Second, and this catches people hard: a Zigbee or Z-Wave network’s pairing lives partly in the coordinator’s own memory, beyond what Home Assistant itself stores. Restoring Home Assistant onto a new machine with the same USB coordinator stick brings your mesh back; losing the stick itself can mean re-pairing every device. Back up the coordinator’s network key too (Zigbee2MQTT and ZHA both let you export it), because that key is what lets a replacement coordinator adopt the existing network rather than starting from scratch. This is one more reason the radio you chose has consequences long after you bought the sensors.

The five-minute setup

If you run Home Assistant OS or Supervised, the Settings → System → Backups panel does scheduled backups natively — pick a cadence, set an encryption password, and it writes local backups on schedule. That covers the “backup exists” half. The missing half is getting each backup off the box automatically. The cleanest way is a community add-on that ships every new backup to remote storage.

The simplest hands-off option for many people is the Home Assistant Cloud (Nabu Casa) backup feature, which stores encrypted backups off-site as part of the subscription. If you’d rather own the destination, add-ons exist to push backups to Google Drive, an S3-compatible bucket, or a Samba/NFS share on your NAS. Here’s the shape of an automation that creates a backup and then the add-on syncs it off-box:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# configuration.yaml — a weekly full backup, excluding the heavy recorder DB.
# The remote-storage add-on watches the backup folder and uploads new archives.
automation:
  - alias: "Weekly Home Assistant backup"
    trigger:
      - platform: time
        at: "03:30:00"
    condition:
      - condition: time
        weekday:
          - sun
    action:
      - service: hassio.backup_full
        data:
          name: "weekly-{{ now().strftime('%Y-%m-%d') }}"
          password: !secret backup_password
          # Exclude the recorder DB folder to keep archives small
          # (configure the exclusion in the backup add-on / UI as supported)

Set the encryption password in secrets.yaml, point your chosen sync add-on at Google Drive or your NAS, and set it to prune old archives so you keep, say, the last eight weekly backups and don’t fill the destination. That’s the whole job. From here on, a dead SD card costs you a card and an hour, rather than your entire smart home.

If you run Home Assistant Container rather than OS, you don’t get the Supervisor backup service, so back up the config directory yourself. A nightly job with Borg or Restic pointed at the Home Assistant config volume gives you the same encrypted, off-box, deduplicated result, and those tools are built exactly for this.

Encrypt it, because a backup is a copy of your keys

A Home Assistant backup contains every credential your setup uses — integration tokens, Wi-Fi passwords in some add-on configs, camera credentials, the lot. An unencrypted backup sitting in a cloud bucket is a plaintext copy of the keys to your house and your accounts. Always set the encryption password, store that password somewhere safe and separate from the backups (a password manager works well; a note in the same Drive folder defeats the point), and understand that if you lose the password the backup is unrecoverable. That’s the point of encryption, and it’s also the footgun — a backup you can’t decrypt is as useless as no backup at all.

How many, how often, and where

Once backups are running off the box, the next questions are cadence and retention, and there’s a sensible middle ground between “never” and “hoard everything forever”.

Match the frequency to how often your setup changes. If you’re actively tinkering — adding devices, rewriting automations most weekends — a daily backup means a bad edit costs you at most a day’s work to roll back. If your system is settled and barely changes, weekly is plenty. The useful habit on top of the schedule is a manual backup right before any big change: before a major Home Assistant version upgrade, before ripping out an integration, before re-jigging your Zigbee network. Those are the moments things break, and a known-good snapshot taken sixty seconds earlier turns a failed upgrade into a two-minute restore.

Retention wants a little thought so you don’t either fill the destination or keep only backups from the last bad week. A rolling window works well: keep the last seven daily backups, the last four weekly ones, and maybe a monthly archive or two. That way a problem you notice today can be undone, and a problem you only spot a month later — a slow database corruption, a setting you changed and forgot — still has a clean copy behind it. Most sync add-ons handle this pruning for you; set the numbers and let it manage the housekeeping.

The principle underneath all of this is the old backup rule that predates smart homes by decades: keep more than one copy, on more than one kind of media, with at least one copy somewhere else entirely. For a Home Assistant box that can be as simple as the working SD card, a copy on your NAS, and a copy in a cloud bucket. Three copies, two locations, and the day one of them fails you barely notice. It’s the same logic that protects the recordings on your Frigate NVR or the flows in your Node-RED instance — anything you’d hate to rebuild by hand deserves a copy that outlives the hardware it lives on.

Test the restore before you need it

Here is the step that separates people who have backups from people who have working backups: actually restore one. Spin up a spare Raspberry Pi or a throwaway virtual machine, install a fresh Home Assistant, and restore your latest backup onto it. You’ll discover the gaps while it’s a calm experiment rather than a 9pm emergency — a missing add-on, a coordinator that needs its key re-imported, a credential the backup didn’t capture.

Do this once when you set backups up, and again after any big change to your system. It takes half an hour and it converts a nervous hope into a known-good recovery. The same discipline applies to everything you self-host; a Frigate NVR full of un-tested recordings or a backup you’ve never restored are the same false comfort wearing different clothes.

Troubleshooting the backup itself

Backups succeed but the archives never leave the box. The sync add-on isn’t running, isn’t authorised, or is watching the wrong folder. Check the add-on log for auth errors (Google Drive tokens expire and need re-linking), confirm it’s pointed at /backup, and verify a fresh archive actually appears at the destination — don’t assume, look.

The backup is enormous and takes forever. You’re including the recorder database. Exclude it from routine backups and keep the history in a monthly full one if you care about it. If your database itself is bloated, that’s a sign to trim the recorder’s retention and exclude noisy entities from history.

Restore fails or comes back partial. Usually a version mismatch (restoring an old backup onto a much newer Home Assistant) or a missing add-on the backup depended on. Restore onto a matching or newer version, and remember that add-on data restores but the add-on repository may need to be added first. This is exactly the sort of thing the test restore surfaces harmlessly.

Zigbee devices are all “unavailable” after a restore. The coordinator didn’t come back with its network intact. If you moved the same USB stick across, re-plug it and let the integration re-establish; if you replaced the stick, you’ll need the exported network key to adopt the old network, or you’re re-pairing. This is the single most painful post-restore surprise, and exporting that key in advance is what prevents it.

The verdict

Home Assistant backups are the highest-value five minutes you’ll ever spend on your smart home, and the fact that they’re free and built in makes skipping them indefensible. The whole discipline comes down to three habits worth building: schedule automatic backups, make absolutely sure they land somewhere off the box, and restore one before you’re forced to. Add encryption and a copy of your Zigbee network key and you’ve covered every realistic failure.

An SD card dying should be a minor annoyance — swap the card, restore the backup, done before the kettle’s boiled. Without backups it’s a lost weekend and a lot of muttering about how you’ll never trust an SD card again. Set this up today, test it this week, and the next dead card will be a footnote rather than a catastrophe.