How to back up Home Assistant properly

Backing up Home Assistant is the difference between a 30-minute recovery and a weekend-long rebuild. After spending hours configuring automations, adding devices, and tuning integrations, a failed SD card or corrupted database wipes all that work. Here’s how to do it right.

Daily automated backups on the box, a weekly versioned second copy on a NAS or external SSD, and one copy offsite. Keep the encryption key somewhere other than next to the backups, take the separate Zigbee/Z-Wave coordinator backups too, and test a restore at least quarterly.

Why local backups beat cloud

Most Home Assistant users run on modest hardware - Raspberry Pi, a mini PC, or one of the official boxes like a Home Assistant Green or a Home Assistant Yellow, discontinued in October 2025 but still running in plenty of houses. The default cloud backup options exist, but they introduce dependency on external services and add latency to restores.

Local backups give you control. You decide where data lives, how it’s protected, and how fast you can recover. If your internet goes down, you can still restore. If a cloud service changes terms or pricing, you’re not locked in.

The built-in Home Assistant backup tool covers more than it used to. It backs up your configuration, database, and add-ons, and since the 2025.1 and 2025.2 releases it can run on a schedule and copy backups off the box on its own - to network storage, Home Assistant Cloud, Google Drive, or OneDrive - with a retention limit you set. What it still will not give you is a full disk image or a deep version history, so layer additional strategies on top.

One thing the archive does not contain is the key that opens it. Backups are encrypted by default, and Home Assistant generates that encryption key once, when you first set up backups. Download the emergency kit from the backup settings page and store it somewhere other than alongside the backups, because nobody can recover it for you and without it the archive is just noise.

Core backup strategy: the 3-2-1 rule

Apply the standard backup rule: three copies of your data, on two different media types, with one stored offsite. For Home Assistant, this translates to:

1. The daily automated backup - Home Assistant’s built-in backup runs on schedule. Configure it to retain 3-7 daily backups. This catches configuration drift and gives you recent restore points.

2. Weekly second copy with real versioning - point Restic, Borg, or Duplicati at the folder where your .tar backups land on the NAS, so you keep a deduplicated version history rather than just the last N archives. If Home Assistant runs in a VM or on a mini PC you control, add a periodic disk image from the hypervisor or from a live USB. On an appliance like the Green there is no supported way to image the eMMC while it is running, so the .tar archives are your recovery path.

3. Offsite copy - Copy those archives to a separate location. rsync to a remote server, a second NAS at a family member’s house, or encrypted cloud storage you control. A fire or theft that takes out your primary hardware shouldn’t also take your backups.

For hardware, consider running Home Assistant on something with proper storage. A Raspberry Pi with a quality SD card works for testing, but SD cards fail frequently in production - a well-documented HA community pain point. A mini PC like a Beelink SER6 MAX with an SSD performs better and survives longer. If you want official hardware, the Home Assistant Yellow includes NVMe expansion that makes local backups trivial. (The Yellow was discontinued for new sales in October 2025; if you can’t find one, a mini PC with an SSD or the Green, whose soldered eMMC still beats microSD, works well too.)

What gets saved

Home Assistant’s backup includes your configuration.yaml, YAML files, the database (home-assistant_v2.db), and installed add-ons. But some things slip through:

Secrets and API keys are covered. Anything you’ve put in secrets.yaml (in your /config directory, alongside configuration.yaml) is included in a full backup. Integration tokens added through the UI live in the .storage directory and are captured too. Even so, plan to re-authenticate some cloud integrations after restoring to fresh hardware - OAuth-style logins often need redoing by hand.

History data is the size problem. The recorder database grows large. Backing up months of history adds storage cost and restore time. Long-term statistics live in that same database, so you cannot carve them out of a backup on their own; instead shrink the database itself with the recorder’s purge_keep_days (default 10) and its include/exclude filters, or leave the history data out of the backup entirely.

Add-on data is captured too. A full Home Assistant backup includes the data directory of every installed add-on, so the MariaDB add-on’s database and your Zigbee add-on’s files are captured automatically. The thing to keep separate is the Zigbee/Z-Wave network credentials, not firmware. ZHA includes its network backup in normal Home Assistant backups; Zigbee2MQTT writes a coordinator_backup.json to its data directory (also captured) that you should additionally keep a standalone copy of. For Z-Wave, a normal Home Assistant backup captures the Z-Wave JS configuration and its security keys, but that is not what saves you when you swap the stick: the network itself lives in the controller’s non-volatile memory, so take the dedicated Z-Wave JS NVM backup as well and keep a copy off the machine. (My walkthroughs on backing up and restoring a Zigbee network and doing the same for Z-Wave cover the coordinator side in depth.)

If you use Z-Wave or Zigbee, keep those coordinator/controller backups with the rest. After a restore, the mesh heals on its own as long as the new coordinator carries the original network credentials; without them, devices need re-inclusion one by one.

Automating without pain

Manual backups get forgotten. Automate with Home Assistant’s built-in scheduler or use a simple cron job. Here’s what works:

Home Assistant’s built-in backup can write straight to network storage you add under Settings > System > Storage (CIFS/SMB or NFS - there is no built-in SSH target), and its retention is a single “keep the last N backups” setting rather than a daily/weekly/monthly rotation. If you want proper generational retention - 7 daily, 4 weekly, 12 monthly - that is a job for Restic, Borg, or Duplicati running against those archives, plus a cron job to sync them offsite.

Test restores quarterly, following my step-by-step guide to restoring Home Assistant from a backup. Restores can fail when the target Home Assistant is older than the backup you are restoring. Better to catch that on a Tuesday evening than during an emergency.

On Home Assistant OS (or a Supervised install, though Supervised was deprecated in May 2025 and is unsupported as of 2025.12), a shell script calling ha backups new --name "weekly-$(date +%Y%m%d)" works. Home Assistant Container has no Supervisor and therefore no ha CLI at all, so there you either call the backup.create_automatic action from an automation or stop the container and archive /config yourself. Either way, pair it with rclone to push archives to Backblaze B2 or a personal S3 bucket.

Tradeoffs worth knowing

Backups have costs. Storage grows over time as your database expands. Restores take longer with more history. Offsite copies require bandwidth and a destination.

If you use Home Assistant Yellow with the NVMe expansion, the SSD eliminates SD card failure but adds cost. Running a full x86 VM with ECC memory costs more but prevents silent data corruption. These aren’t required - most people succeed with basic setups - but they reduce failure modes.

For those with Hubitat or HomeKit alongside Home Assistant, remember those platforms have separate backup needs. Hubitat’s local backup is less thorough than Home Assistant’s; export configs regularly. HomeKit backups live in iCloud and Apple’s ecosystem - less granular control but automatic.