How to restore Home Assistant from a backup, step by step

To restore Home Assistant, open Settings > System > Backups, pick the backup and choose Restore. On a fresh install, upload the backup from the onboarding screen instead. Either way you need the encryption key from the backup emergency kit, and the target should run the same Home Assistant version as the backup or a newer one.

I’ve done this and migrated twice, and it went fine. I had some hiccups getting the radio to show up when I went from a Pi to Unraid, just due to my own incompetence: on a VM, the Zigbee or Z-Wave USB dongle has to be passed through to the VM before Home Assistant can see it. I’ll be doing it again soon, when I move the VM host to a high-availability cluster. If your system is down right now, skip to step 1.

Backing up Home Assistant is the difference between a 30-minute recovery and a weekend-long rebuild, and restoring a backup is how you move to new hardware, replace a dead drive, or recover from a bad upgrade without losing your automations, integrations, and device setup. This guide walks through both, mainly for Home Assistant OS, where the Supervisor-backed backup system lives. Since Home Assistant 2025.1, backing up and restoring work on every install type, so the UI steps below apply to Home Assistant Container and Core as well.

Short version: 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. Restore from the Backups page in the UI, from the onboarding upload on a fresh install, or with ha backups restore on systems that have the Supervisor. Have the encryption key and note the version before you start, and check the dashboard and logs afterwards.

One more thing before you plan a rebuild: Home Assistant deprecated the Supervised and Core installation methods on May 22, 2025, and both became unsupported from release 2025.12 onwards. The supported install types today are Home Assistant OS and Home Assistant Container. If you already run Supervised, the Supervisor is still there and everything below still applies to you. But if you are standing up a fresh system to restore into, restore onto Home Assistant OS (or Container) rather than building a new Supervised install.

What gets saved

The built-in Home Assistant backup tool covers more than it used to. It backs up your configuration.yaml, YAML files, the database (home-assistant_v2.db), and installed 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.

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. 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.

One thing the archive does not contain is the key that opens it. Backups are encrypted by default. Since Home Assistant 2025.1 the old backup password has been replaced by an encryption key that Home Assistant generates once, when you first set up backups, and stores in the backup emergency kit. 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. You can switch encryption off for a given backup location if you have a reason to (backups uploaded to Home Assistant Cloud are always encrypted either way), but the default is on.

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.

A backup that only lives on the same SD card or SSD as your install will not help you when that drive dies. 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 with an SSD, such as a Beelink SER6 MAX on the used market since Beelink no longer sells the SER6 new, performs better and survives longer. If you want official hardware, the Home Assistant Green, whose soldered eMMC still beats microSD, works well too. (The Home Assistant Yellow was discontinued for new sales in October 2025, though it is still running in plenty of houses.)

Automating without pain

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

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. A Home Assistant Cloud subscription adds 5 GB of encrypted off-site storage that holds your most recent backup. The built-in encryption protects the archive contents, so store the file wherever is convenient and keep the encryption key somewhere separate. 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.

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.

Test restores quarterly, following the steps below. 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.

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. Cloud backup destinations also introduce a dependency on external services and add latency to restores.

If you already run a 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.

Step 1: prepare your environment

Before you start a restore, make sure you have the backup file and know where it is. On Home Assistant OS, backups live in the /backup directory and are .tar archives; on Container and Core installs they land in a backups folder inside your config directory. If you are moving to new hardware, copy that .tar file somewhere you can reach it from the new machine, such as a USB drive or your computer.

If you’re restoring during a fresh install, you can restore directly from the onboarding screen. When you first boot a new Home Assistant OS install and reach the onboarding page, there’s an option to upload a backup instead of creating a new account. This is the cleanest way to migrate to new hardware.

One sensible precaution: note the Home Assistant version the backup was created on. Restoring into a much newer version usually works because Home Assistant runs migrations, but restoring a newer backup into an older version can fail. If you can, restore onto the same or a newer version.

Backups are encrypted by default, and that means you need the encryption key from the emergency kit to restore. Keep it somewhere safe and separate from the backup itself, or the archive is useless to you.

Step 2: restore the backup

There are three common ways to restore, depending on your situation.

From the UI (most common). Go to Settings > System > Backups. If the backup is already on the device, click it and choose Restore. You can do a full restore (everything, including add-ons and Supervisor settings) or a partial restore (pick just Home Assistant Core, specific add-ons, or folders). If the backup is on your computer, use the upload option to send it to the instance first, then restore it.

During onboarding. On a brand-new install, the onboarding wizard offers an “Upload backup” path. Point it at your .tar file, supply the encryption key if prompted, and it rebuilds the system from the archive.

From the command line (Supervisor only). If the UI is unreachable but the system still boots, you can use the Supervisor CLI over SSH or the console. List your backups, then restore by slug:

ha backups list
ha backups restore <backup-slug>

Add --password <your-key> if the backup is encrypted. Note this only works on Home Assistant OS and Supervised installations, because the ha command comes from the Supervisor. Home Assistant Container (Docker) and Core (venv) installs have no Supervisor and therefore no ha command at all. That does not leave them stranded: since Home Assistant 2025.1 they can create and restore backups from the same Backups page in the UI. Their backups simply cover Home Assistant itself rather than add-ons and Supervisor settings, because those installs have neither.

After a restore, some integrations that rely on local pairing may need attention. HomeKit-exposed devices and any integration tied to a specific host or token can need re-authentication once the system comes back up. If you’re also swapping the Zigbee or Z-Wave USB coordinator - say, moving to a Home Assistant Connect ZBT-2 for Zigbee or a Home Assistant Connect ZWA-2 for Z-Wave - remember that each radio’s network is stored on the stick itself, not only in the Home Assistant backup. See how to back up and restore your Zigbee network and how to back up and restore your Z-Wave network before you move radios.

If you’re restoring into a virtual machine, pass the USB radio through to the VM in the hypervisor before you expect Zigbee or Z-Wave to come back. That’s the step I tripped on when I moved from a Raspberry Pi to a VM on Unraid: the backup restored fine, and the radio didn’t show up until the dongle was passed through.

Step 3: verify and test your setup

After restoring, give the system a few minutes to start all services, then check the dashboard. Confirm your devices show up and report sensible states rather than “unavailable.”

Open Settings > System > Logs and look for errors. A handful of warnings on first boot are normal as integrations reconnect; persistent errors pointing at a specific integration are worth investigating.

Run a couple of your most important automations manually to confirm they fire. If you use YAML configuration, you can validate it from Settings > Tools > YAML > Check Configuration before reloading, which catches syntax problems without a full restart.