A Home Assistant backup is an encrypted file containing the configuration and data needed to restore the installation.
All this digital effort resides physically on a single storage medium (the SSD or eMMC memory of our server). As we know from systems engineering experience, physical hardware always fails eventually. It’s not a question of if it will happen, but when.
If tomorrow your Mini PC suffers a power surge that fries the motherboard, or the SSD exhausts its write cycles and corrupts the Home Assistant database, you’ll face the nightmare of having to rewrite all the code and re-pair every light bulb in the house from scratch.
To avoid this disaster, we must implement the last pillar of any production deployment: an automated, unattended, and offsite backup strategy.
The native HAOS backup system
One of the biggest advantages of choosing the Home Assistant OS (HAOS) architecture is that it includes an extremely powerful backup manager integrated directly into the system.
This system prepares components, packages the configuration, and saves the backup in a .tar file. Current backups can be encrypted and require keeping their emergency key to restore them.
There are two types of native backups:
- Full backup: Includes directories like
/config,/share,/ssl, and/media, plus data from installed add-ons. It does not need to save container images, which are re-downloaded during restoration. - Partial backup: Allows selecting specific directories and add-ons. Useful for reducing size or recovering only part of the system.
The default architectural flaw
If we go to Settings > System > Backups, we can generate a full backup with a single click. However, this manual method has a critical design flaw if we stop there:
By default, Home Assistant saves that .tar file in the /backup folder on the same hard drive where the operating system is installed. A backup stored on the same physical media as the original data is not a backup; it’s an illusion. If the disk dies, you lose the system and you lose the copy.
To design a robust strategy, we must apply the industry standard.
Home Assistant also allows scheduling automatic backups from its own interface. This is a huge improvement over the early years of the project. Still, the important point remains the same: the backup must end up somewhere else, not just on the server’s disk.
The 3-2-1 rule in home automation
In systems administration, we apply the 3-2-1 Rule to guarantee data integrity:
- Keep 3 copies of the data (the original in production and two backups).
- Stored on 2 different physical media (e.g., the server’s SSD and a local NAS).
- Keep 1 copy offsite outside the physical location (in the cloud, in case the house suffers a fire, theft, or flood).
Since automating this manually with Bash scripts and cron would be tedious, the Home Assistant community has developed very convenient tools that solve this problem in a short time.
External backups to Google Drive
Home Assistant includes an official Google Drive integration that can act as a backup destination. Once configured, it appears alongside local storage and allows applying its own retention policy.
If you use Home Assistant Cloud, you can store the latest backup there within the limit offered by the subscription. The official Google Drive integration is an alternative when we prefer to use our Google account’s space.
- Go to Settings > Devices & Services and add the Google Drive integration.
- Configure the Google OAuth credentials following the official wizard.
- Authorize the account and verify that Google Drive appears as a location in Settings > System > Backups.
- Activate that location in the automatic backup settings and save the emergency kit outside of Home Assistant.
Once linked, we must configure retention to avoid filling the available space. Home Assistant allows defining how many copies each location retains.
A recommended configuration for a home environment would be:
- Home Assistant Backups (Local): Keep 3.
- Google Drive Backups (Cloud): Keep 7 (one for each day of the week).
- Frequency: Perform an automatic backup every 24 hours (typically early morning, at 03:00 AM, when the system has less workload).
With this configuration, Home Assistant will automatically rotate the backups and delete the oldest ones according to the chosen policy.
If the database is very large, review which entities recorder stores and their retention period. The database is inside /config, so a partial backup that includes the configuration will also include it; the proper approach is to reduce it first using the recorder options.
Local alternatives: NAS and network storage
If you are one of those purists who refuse to upload a single byte to the Google cloud, or if you already own a NAS (Network Attached Storage) server like Synology or TrueNAS on your local network, there is an identical alternative for local network storage.
Home Assistant OS allows adding NFS or CIFS network storage and marking it as a backup destination. There are also integrations with destinations like Synology DSM or OneDrive.
Ideally, we would combine one local network destination and one external one, like a NAS for fast restorations and Google Drive to fulfill the offsite requirement of the 3-2-1 rule.
How to test restoration
There’s a saying in systems engineering: “A backup that has never been tested is a Schrödinger’s backup; it may work or it may not.”
It’s useless to have 100 files on Google Drive if, when disaster strikes, we don’t know how to inject them into a new machine. The restoration process in Home Assistant OS stands out precisely for its simplicity.
Let’s imagine the worst-case scenario: the server has burned out. We buy a new Mini PC.
Flash Home Assistant OS from scratch onto the new SSD using BalenaEtcher.
Boot the server and access the local IP on port 8123.
The initial Home Assistant welcome screen will appear (where it asks us to create the first user).
Do not create any user. On the welcome screen, select the option to upload a backup.
Download our latest .tar file from Google Drive to our computer.
Upload it through that initial screen.
Home Assistant will restore the selected parts and re-download the necessary add-ons. After the reboot, we must check integrations, radios, add-ons, automations, and credentials, because the result also depends on the connected hardware and what the backup included.
For Zigbee, recovery depends on the software and the coordinator used. ZHA keeps copies of its network and allows migrating compatible radios; Zigbee2MQTT saves its data in its configuration directory. Include that data and keep a specific copy of the coordinator when the platform offers it.
What really needs testing
You don’t need to burn the server to test a backup. We can do a reasonable drill by restoring a copy to a virtual machine, a test Raspberry Pi, or a secondary Mini PC disconnected from the actual installation.
The goal of the drill is not just to see that Home Assistant starts. We also want to verify that the add-ons return, the integrations appear, the automations exist, and the secrets have been restored. If you use Zigbee2MQTT, it’s also advisable to verify that its add-on data is included in the copy.
Write down, somewhere external to Home Assistant itself, the minimum recovery data: server IP, backup user, backup location, remote domain, and where the Zigbee dongle is stored. At the moment of disaster, you’ll be grateful not to have to remember everything by heart.
If you protect backups with a password or encryption, store that key outside of Home Assistant: a password manager, a well-kept physical note, or both. An encrypted backup whose key no one remembers is, for all practical purposes, a lost backup.
