Home Assistant Backups: Local, Automatic, and Off-Server

Every mistake this course has warned about, a bad YAML edit, a failed update, a dying SD card, becomes a minor, manageable inconvenience instead of a genuine disaster if you have a good backup. This lesson makes sure you actually do.

An intro: when a drive dies

Every storage device fails eventually, an SD card in a Raspberry Pi, an old hard drive repurposed for Home Assistant, a NAS drive years into service, it's a question of when, not if. Without a backup, a failed drive means rebuilding every integration, every automation, every carefully chosen name and area from Module 6, entirely from memory, a genuinely miserable multi-day project. With a backup, it means buying a new drive, restoring, and being back online within the hour. This lesson exists entirely to make sure you're in the second group.

What a backup in Home Assistant actually is

A Home Assistant backup, created from Settings, then System, then Backups, is a single compressed archive containing your entire configuration: every integration's settings, every automation, every dashboard, every user account, and optionally your historical sensor data too. Restoring one puts your system back to exactly the state it was in the moment the backup was taken, on the same hardware or genuinely different hardware entirely, which is precisely what makes it such a powerful safety net against nearly any category of disaster this module has discussed.

What's inside a backup

A full backup includes your entire configuration directory, every add-on's own configuration and data, your user accounts and their credentials, and, if you choose, the historical database Module 6 and later modules will fill with sensor readings and event history. You can also create a partial backup, choosing specific add-ons or folders only, useful for a quick safety net before a small, targeted change rather than a full system snapshot every time.

What a backup doesn't solve

A backup stored only on the same physical drive as your running Home Assistant installation doesn't protect against that drive failing entirely, taking both the live system and its only backup down together. A backup you've never actually tested restoring doesn't guarantee it will work when you genuinely need it to. And a backup doesn't protect against Zigbee radio failures or physical device problems, those are hardware issues a software snapshot simply can't fix. This lesson addresses the first two gaps directly.

Local backups

A local backup, stored on the same drive Home Assistant runs from, is the fastest to create and restore, and it's the default location backups land in unless you configure otherwise. It's a genuinely useful first layer, protecting against software problems, a bad update, a broken configuration change, but it offers zero protection if that physical drive itself fails, which is exactly why this lesson doesn't stop here.

Off-server backups

An off-server backup, copied somewhere other than the drive Home Assistant runs from, a NAS, a USB drive, cloud storage through a backup add-on, is what actually protects you against total drive failure. Nabu Casa subscribers, from Module 7, get automatic encrypted cloud backup storage included, genuinely the simplest off-server option available. Readers without Nabu Casa can use a dedicated backup add-on to copy backups automatically to a NAS or cloud storage provider on a schedule, covered further in this lesson's automatic backup section.

Automatic backups

Home Assistant's built-in backup schedule, configurable from the same Backups page, can create backups automatically on a recurring basis, daily or weekly, without you needing to remember to click a button. Set this up once, choose a schedule that matches how frequently your configuration actually changes, and combine it with an off-server destination so the automatic schedule is doing real, meaningful protective work rather than just accumulating local copies next to the very drive they're meant to protect against.

Backups before risky changes

Beyond your regular automatic schedule, take a manual backup immediately before anything genuinely risky: a major update, covered in depth in Lesson 5, a significant YAML edit, or installing an unfamiliar HACS extension from Module 6. This habit, already introduced back in Module 6's File Editor lesson, is worth repeating here because it's simply the single most effective five-minute habit in this entire course for undoing a mistake cleanly, rather than trying to manually reverse it under pressure.

Naming your backups

Give manual backups a clear, descriptive name, "before Zigbee integration update" rather than the generic default, following the same naming discipline Module 6 established for entities and devices. When you're staring at a list of a dozen backups trying to find the right one to restore, a clear name saves genuine, real time compared to guessing based on a timestamp alone, particularly under the mild stress of an actual system problem.

Testing a restore

A backup you've never tested restoring is a hypothesis, not a safety net. If you have spare hardware, a second SD card, an old Raspberry Pi, restore a recent backup onto it once, just to confirm the process works end to end and that the resulting system genuinely matches what you expected. If spare hardware isn't available, at minimum confirm the backup file exists, has a reasonable file size, and isn't corrupted or empty, a small but genuinely meaningful sanity check that takes moments.

How many backups to keep

Keep more than one backup at all times, a single most-recent backup doesn't protect you if that specific backup itself turns out to be corrupted or was taken moments before a problem occurred. A reasonable default is keeping your most recent handful of automatic backups plus any manual ones tied to significant changes, letting older automatic backups age out naturally rather than accumulating indefinitely and quietly consuming storage space you'd rather use for something else.

Backups and privacy

A full backup contains genuinely sensitive information, your account credentials, your network configuration, potentially months of sensor and camera-related history. Treat backup files with the same care as the credentials Lesson 3 covered, encrypted at rest where your storage supports it, and never uploaded to a public or shared location. Nabu Casa's cloud backups are encrypted by default specifically for this reason, and any self-managed off-server destination is worth confirming offers the same protection before relying on it.

Exercise after this lesson

Set up an automatic backup schedule now if you haven't already, confirm it has an off-server destination configured, and take one manual backup today, named clearly, as your first genuinely tested checkpoint. If you have spare hardware available, this is also the moment to actually try a restore, confirming the whole process works before you ever genuinely need it to.

Your backup notebook

Add a Backups section to your notebook noting your schedule, your off-server destination, and the date you last actually tested a restore. This single entry means that months from now, in the middle of an actual problem, you'll know immediately whether your backup situation is genuinely solid or whether it's quietly drifted out of date since you last checked.

Restoring after a full reinstall

If your original drive fails entirely and you're rebuilding on fresh hardware, install Home Assistant on the new drive following the same process Module 5 walked you through, then, during that initial setup, choose to restore from a backup rather than starting a new configuration from scratch. Point it at your off-server backup file, and within a few minutes your integrations, automations, dashboards, and accounts all return exactly as they were, no manual reconstruction required. This is precisely the scenario this lesson's off-server requirement exists for, a total hardware failure that a purely local backup could never have survived in the first place.

A real story: the SD card that finally gave out

A reader in this course's community ran Home Assistant on a Raspberry Pi for nearly two years without incident, then, one ordinary evening, the SD card simply stopped responding entirely, mid-automation, with no warning at all. Because they'd set up an automatic weekly backup to a NAS months earlier, following essentially this exact lesson, recovery meant buying a new SD card the next morning, flashing it, and restoring their most recent backup, back online in under an hour with a loss of only a few days of automation tweaks they barely remembered making. Their honest reflection afterward was that the backup had taken perhaps ten total minutes to originally set up, against what would otherwise have been a genuinely painful, exhausting weekend spent rebuilding two full years of accumulated configuration entirely from memory.

Backups and your Zigbee network

A full Home Assistant backup includes your Zigbee coordinator's network information, meaning devices you pair in Module 9 and beyond generally reconnect automatically after a restore, without needing to be individually re-paired one at a time. This isn't guaranteed in every single scenario, particularly if the coordinator hardware itself changed, but it's a genuinely pleasant surprise the first time you experience it, one more reason this lesson matters more, not less, once your smart home actually starts filling up with real physical devices in the modules ahead.

Choosing where to store off-server backups

If you already own a NAS, it's a natural, convenient off-server destination, on the same local network but on genuinely separate storage hardware from your Home Assistant server itself. Cloud storage, whether through Nabu Casa's built-in option or a general-purpose provider connected via a backup add-on, adds true geographic separation too, protecting against scenarios a NAS in the same building wouldn't, a fire, a flood, a theft. Neither option is strictly required over the other, what actually matters is that your backups exist somewhere physically separate from the drive Home Assistant itself runs from.

Backup retention and storage space

Full backups, particularly ones including historical database data, can grow meaningfully large over time, worth keeping an eye on if your storage is limited. Most backup solutions, including Nabu Casa's, let you configure how many backups to retain automatically, deleting the oldest as new ones are created, so this is generally a set-once decision rather than an ongoing chore. If storage becomes a genuine constraint, excluding the historical database from routine automatic backups while still including it in occasional manual ones before major changes is a reasonable middle ground worth considering.

Backups as part of your emergency plan

Lesson 7 closes this module with a full emergency plan for when Home Assistant won't start, and restoring a backup is one of its later, more decisive steps, worth understanding now rather than encountering that section cold under pressure. Knowing where your backups live, how recent they are, and roughly how long a restore takes is exactly the kind of calm, pre-established knowledge that turns a stressful evening into a routine, manageable fix, which is really this entire lesson's underlying goal.

Backups when moving between HAOS and Container

If you ever migrate from HAOS to Container or vice versa, Module 5's two installation paths, a standard backup generally transfers your configuration cleanly between them, though add-ons specifically tied to HAOS's Supervisor won't carry over automatically to a Container setup that lacks it, worth checking in advance if a migration like this is ever on your radar. This isn't a common scenario for most readers of this course, but knowing backups aren't strictly locked to one installation method is useful context worth having, particularly if your needs or hardware ever change down the road.

Third-party backup add-ons

Beyond Home Assistant's own built-in backup system, several well-regarded community add-ons, installable through HACS from Module 6, add features like uploading directly to a wider range of cloud storage providers, more granular scheduling, or automatic pruning of old backups by more flexible rules than the built-in defaults offer. These are genuinely optional, the built-in system covers the core need this lesson describes perfectly well on its own, but they're worth knowing about if your specific setup calls for something more customized than the default options provide.

When a backup itself fails to create

Occasionally a backup attempt fails outright, usually due to insufficient free storage space on the drive, a misbehaving add-on refusing to pause cleanly during the snapshot, or a corrupted file somewhere in the configuration being backed up. Home Assistant's logs, covered further in Lesson 7, will generally point to the specific cause. Treat a failed backup attempt as something to investigate immediately rather than simply retrying and hoping it works the second time, since a silently failing backup schedule defeats this entire lesson's purpose without you necessarily realizing it until the exact moment you actually need one and discover it isn't there.

Checking that a scheduled backup actually ran

Beyond the periodic notebook check this lesson already recommends, it's worth glancing at the Backups page itself every so often, confirming the most recent entry's timestamp actually matches your configured schedule rather than assuming silently that everything is working correctly in the background. This takes seconds and closes the loop on the previous section's warning about silent failures, turning "I set up automatic backups once" into "I know, right now, that my backups are current and genuinely working."

Key takeaways

With real, genuinely tested backups now firmly in place, Lesson 5 covers updates, when to click right away and when to wait, without ever breaking your carefully built system.