Asking for advice before a major version upgrade

Installation
, ,
1

Hello everyone,

I’ve been using HA since 2017 and absolutely enjoying it. thanks in advance for any help.
I’ve reached a point where i would like to upgrade only because zigbee2mqtt requires it.
Since yaml deprecation started I’ve done upgrades only when it was unavoidable, unfortunately it would be too long to explain from a devops point of view and it has been discussed too long in the past, therefore I’ll try to sum it up in one sentence:
The main reason is configuration backups and UI interaction requirements.

I’m currently running version 2021.10.7, since the gap is huge i’m considering starting from scratch even though my setup is quite complex.

TLDR
However, before I upgrade I would like to ensure I can backup HA configuration, restore and redeploy it automatically from a devops point of view.
I read of many native backup restoration issues, I read that changes to some integrations may require removing it completely and re-adding it, these examples are show-stopper for me.

Desired procedure for example would be, pull the configuration from git, fire up a container and HA is fully restored, no UI interactions.
I was wondering if other users could share their approach to achieve this.

my current state:

  • I’m running a mini-pc and Ubuntu 22.04 where OS installation and configuration are fully automated by ansible.
  • HA and all of its ecosystem listed below are container based and automatically deployed by ansible.
  • Home assistant core 2021.10.7
  • no cloud integrations other than google assistant.
  • mysql db
  • zigbee2mqtt
  • mosquitto server
  • dehydrated
  • frigate
  • wireguard
  • prometheus
  • grafana
  • I barely use the UI.
  • HA history can be wiped at any time, it is only kept for 3 days in HA/DB since it is stored in TSDB for long-term.

Thank you!

2

Whether you do this (and I’m not even sure what exactly you mean), you’re going to have to work through tons of changes. Personally I’d follow the upgrade path by installing the last version of every month.

I know you’re trying to be brief and I work in the industry, but this doesn’t really mean anything to me. Backups are possible and you control the UI. Unless you use a ton of custom components, this shouldn’t break often.

But then you say:

So, I don’t know…

Otherwise, your setup seems very well though through. Looking at your list, there’s really not anything that should’ve been problematic to upgrade (except for Frigate and zigbee2mqtt that I don’t use, since I don’t have a large security setup or Zigbee devices). So, your “problems” would then be related to HA upgrades only.

Do you mean no UI access during the upgrade? Use nginx or FW to block access.

Built-in ones? I haven’t seen that — or where I have, it’s user error or something else.

:man_shrugging: Honestly, keep automating away as you have (it’s great), but I’d find a way to keep up better with upgrades, even if it’s bi-monthly or quarterly.

3

Thank you for your help and detailed reply!

My initial post may have been too brief, I will try to answer your questions and ask more specific questions, thank you!
"starting from scratch" means I plan to fire up a container of the latest HA version without any previous configurations, I will have to reconfigure all of the integrations from the UI, this is definitely bad practice and having backup integration is not gonna change that.
I’m not fully up to date and please correct me if I’m wrong, the backup integration is nice and simple, but it seems like “black box”, what do you do when a restore fails?

a brief look at the forums is enough to find multiple examples of this, here is one

I’m willing to go through this only if I’m certain there is a proper way to really backup and recreate (not only restore) HA fully.

I do not want to rely on UI for anything unless i want to manually turn on/off a device or look at the stats, even in this cases i usually use grafana, set a physical zigbee switch or use home-habit.
I know backups can be done from the UI and even from background automations, but I wonder if a backup can be restored without UI interaction?

What do you do when you change an integration config? let’s say you change an ip address of the broadlink remote integration, do you backup before and after such a simple change?
in case you don’t, do you wait for the next scheduled backup to run in order to backup these changes?
how do you keep track of what changed between two snapshots?
have you ever restored a snapshot and had to re-apply changes right after restore is finished?

git so far allowed me to track every single change in configuration seamlessly and revert back quickly if needed.
do you create a backup after every change in configuration? how long would it take to create a backup?
how long does it take to restore from a snapshot?

I want to minimize UI interactions due to unnecessary effort in configuration, I don’t mind if it is accessible or not for security reasons, sorry if that i was not clear on this.

When i started in 2017 there where many major changes and improvements which caused things to break, I understand and accept this as part of being an early adopter.
I used to update it frequently and keep it up to date, but this is not the case right now, my HA has reached a point where it is large, useful and stable. I do not want to break it often due to minor changes that I won’t even use, thus my approach changed.

4

You haven’t been very specific about which type of HA installation method you are using (unless I’ve missed it above somewhere…)? That will determine what kind of back up options are available.

I run my HA in a Docker container (HA Container install method) and I backup my config by manually copying my entire config directory on major config changes and right before a monthly update. Snapshots aren’t available for HA Core or HA Container installs, only for HA OS or HA Supervised installs.

But either way as far as I know there is no way to create a backup and do a restore without interacting with your system in some way whether it’s via the UI in HA or the command line in the OS.

But I will add another vote for just upgrading one release at a time and fix any breaking changes that affect your system with that upgrade and then move to the next. I think that will be the most logical way of doing it and is likely going to be easier in the long run to deal with the breaking changes.

I don’t see any value in making a backup to restore from aside from something catastrophic happening and you want to restore to the last know good config/HA version combination (still a good thing to do that reason). It just seems like you will still need to tend to the possible breaking changes from your current version to the HA current version.

5

I wondered too. They mention HA Core and that everything’s Dockerised, but I’m not sure whether it’s HA Container or their own Docker one.

6

Yes, I would definitely not like to reconfigure all my integrations, which is why I think you should rather upgrade. Keep in mind that where integration configs have moved from YAML to config flow (UI), it’s typically handled well for you (for built-in ones) and all you need to do is to remove the legacy YAML config.

Do you run a SQLite DB (the default)? If not, you need to make your DB backup separately.

Otherwise, HA has a collection of YAML and JSON files, with the JSON files being the internal storage. This sits in a .storage directory. Typically, HA backups are just gzipped tarballs of your config directory and as a minimum that’s all you need. Integration configs are in the JSON files. Depending on your exactly installation method, there could be other things.

I don’t, but I mostly use DHCP, so it doesn’t matter if it changes and autoconf discovery typically makes it seamless. Once a device is integrated, (almost) all that matters are the entity IDs.

Yes, and I’ll apply the delta from GitHub, in case I made changes since the last backup. This only applies to YAML config though. The JSON data will be whatever’s in the backup.

For big changes, I will, e.g., before an upgrade. For day-to-day changes, generally not. My backups are super fast and only takes a few seconds. My DB backups take a little longer, but maybe a minute or so. Restoring a backup is basically copying files back – so, it’s really quick.

Unfortunately, this has been a point of heavy contention with the move from YAML to config flow (UI) for integrations. It would be beating a dead horse at this stage, unfortunately. There’s also been a proposal to improve the situation with JSON, but that’s been rejected (for now). If this happened, your idea of automating provisioning becomes a lot more feasible. That said, nothing stops you from fiddling with your JSON files, but it’s discouraged, since you can irrevokably break your system if you can’t restore from a backup.

1 Like
7

I understand this would be “beating a dead horse”, therefore I tried to keep this thread short and avoid going into this discussion.
I needed to understand better what i’m going into and whether i want to, before accepting this bad practice changes and spending days to upgrade, @parautenbach Thank you very much for your help and lots of valuable information.

If a backup is similar to doing an rsync or packaging a tarball of the configuration directory, it seems reasonable.
I’m also relieved to know that backups and restore are a matter of seconds and not 45 minutes as the backup documentation page states, i guess it takes into account the media and other things.

The ip address was of course just an example, I don’t often change ip addresses as i use address reservation.
I use the official home assistant container deployed over Ubuntu and a basic docker engine.
I use an external mysql db, as i mentioned the db is not important and can be wiped at any minute, so no need for backup.