Backup strategy

[asanseau (Alex)]

Hello. I’m planning to run Home Assistant OS on Odroid N2+ (128 GB eMMC).

What’s included in HAOS built-in backups? Is it only devices configurations? Does it also contain log and history? Does it also include the OS itself?

I’d like my backups to cover the following scenarios:

• where I misconfigured an item or accidently amended/deleted a file. Id’ like to come back to a previous known/working state.
• where the disk is corrupted. I’d like to be able to restore the OS, configurations, logs and history… as everything were at the start of the month for instance.

What would be the best strategy in terms of backups in these scenarios? Can I solely rely on the built-in back up process? Or would I need to take a copy (image) of the entire eMMC disk? (which requires taking the Odroid offline I reckon?)

[CentralCommand (Mike)]

@asanseau

What’s included in HAOS built-in backups? Is it only devices configurations?

No it a lot more then that. It’s all your HA config, all your addons config, all data from your addons and everything in your HA folders (besides config that’s also share, ssl, media and addons). Although you can exclude some or all of this

@asanseau

Does it also contain log and history? Does it also include the OS itself?

History - yes usually. If you use the default DB option then its a sqlite file in /config and the entire /config folder is backed up. If you use the MariaDB addon (or another addon which provides the DB service) then yes as long as you include that addon in the backup. If you host the DB completely outside of HA then no you’d have to separately back up history.

Log - no. The log is the journal on the host OS and this isn’t backed up. The home-assistant.log file in /config will probably be included but this is a tiny subset (only core logs and only since the last restart). There’s no way to get your actual logs included in the backup currently, you’d need to handle this separately. See here for how to access your journal logs in HAOS, you could set up a backup strategy using SSH with this.

OS - no. When restoring a backup from scratch you first have to flash the OS. Then you can restore the backup during onbording. But backups are not a flashable image, the OS is not included.

@asanseau

where I misconfigured an item or accidently amended/deleted a file. Id’ like to come back to a previous known/working state.

Backups can theoretically cover this? You would have to remember to take one before every change. To my knowledge there is no way to set up something which automatically takes a backup before applying a change to automate this.

I think you might be interested in the git pull addon which lets you manage your config as a git repo. That being said it only works with integrations that are configurable in YAML. Many integrations are UI-only now and those can’t be managed this way. For those if something went wrong you can only really revert from backup and that’ll revert back to whenever you last remembered to take a backup.

@asanseau

where the disk is corrupted. I’d like to be able to restore the OS, configurations, logs and history… as everything were at the start of the month for instance.

Backups are your closest thing but as I said it won’t cover OS or logs. For OS images of older versions are still accessible so you should always be able to flash what you had. But logs you’d have to deal with separately.

[asanseau (Alex)]

Thanks very much for such a detailed response!

Is there a guarantee of backward compatibility? So for instance, could OS version n restore backups taken by OS version m, where m < n?

Or would it be safer to first restore same version of OS when the backup was taken, and then after the restore upgrade the OS?

[CentralCommand (Mike)]

So OS isn’t actually part of taking and restoring backups tbh, its all supervisor. And OS has a pretty good track record of being backward compatible here. In fact I was just working on this RFC which is caused by the fact that some people are trying to update systems that are very far behind on OS updates. Supervisor has been auto-updating for them for years in some cases (the people on V5) and not had any issues.

I’m not sure if I can point you to any particular documentation that spells this out but I’d say so far evidence suggests that you don’t have to worry too much about this. Backups (and many many versions of supervisor and core) work fine with any version of OS that you’d seek to install these days.

If you want to be extra cautious though there’s no harm in flashing the same OS version, restoring backup and then updating. You don’t have to flash to update for reference, you can update the OS right from the app. So both options are pretty easy.