add support to home assistant core / container

[anubisg1]

starting from version 2022.4, backups are supported for core and containers...

https://www.home-assistant.io/blog/2022/04/06/release-20224/#backups-for-home-assistant-core--container-installs

it would be great to add support to this methods. This addon is so important that it's the only reason why i still use a supervised installation instead of moving fully to kubernetes (or before then docker-compose)

[sabeechen]

I'd like to do this, but the way this addon is currently written depends heavily on running inside one of the docker containers that the supervisor provides. It "should" be possible to write it as something that runs directly inside of a core install, but it would be a significant rewrite of a good part of the addon.

I'd like to do this, but because of how much work it would be I 'm going to have to list this as a "someday" goal that needs a lot more investigation before I can promise if or when it'll happen.

[anubisg1]

Can you please describe what dependencies you have on the supervisor? In principle the addons are just containers that you can run anywhere and as long as you can call apis against the core it should be "fine" (of course the devil is in the details so that was a gross oversimplification)

[sabeechen]

Sure, here are the high points as far as I can see:

• The addon makes use of the supervisor API to create/manage backups. I'm not sure if the backups created directly in core installs have an API (nothing in the docs yet)
• The addon has a lot of configuration options and a relatively complicated workflow to authenticate with Google Drive, which right now is handled through the Web-UI. This UI would need to be re-written within Home Assistant's UI framework. There is a non-trivial amount of code and logic in the UI.
• If the addon is integrated into Home Assistant core, releases of the addon would be tied to Home Assistant releases. As a separate addon I get full control over the release cycle, dependencies, runtime environment, etc. This might seem like a small point, but as the only person developing this addon having full control over the release schedule and runtime environment really saves me time and gets things done faster.
• Its not clear to me if backups created through the "core" backup also include the extra stuff (folders, addons, etc) included in "supervised" installs if the core backup is done on a supervised installation. If they don't, then I'd have to publish and maintain two versions of this project, one as an addon for supervised installs and one as an integration for core installs. If they do, then I'd have to write some kind of migration path for having the current addon users migrate over to using the new "plugin" method without losing their configuration and then deprecate this project.

None of this stands out to me as insurmountable, its just a good deal of work to determine what is the best path forward and then also a lot of work to execute on it. Eventually I want this project to be an integrated part of Home Assistant. The problem is how much time I'm able to dedicate to new features at present.

[anubisg1]

Thank you a lot. I'll be looking into those points and see if I can lower the entry bar for you either by providing documentation or even PRs.

[sabeechen]

Thanks, I could see this being a good move for the addon eventually if I could get the full set of functionality it needs inside of Home Assistant core.

[anubisg1]

All right, so i looked a bit more into it.

• the backup integration used to provide backups of the core uses websockets api as can be seen here https://github.com/home-assistant/core/tree/dev/homeassistant/components/backup
• regarding point 4, i am going to test it this weekend and come back to you with more details
• for points 2 and 3, it is not expected (at least at this stage) to change how the addon works. Specifically, like all the other addons can be installed via the supervisor or as external containers, also the gdrive back would be the same. A user would install a separate container, just not by using the supervisor addon store. this will allow you to:

1. keep your own release cycle
2. maintain all the advance google authentication logic into the addon with little rework
3. hopefully limit the amount of (re)work needed

[sabeechen]

the backup integration used to provide backups of the core uses websockets api

Ah good, the websocket API looks like it would let the addon do everything it needs, though I really wish they'd keep feature parity with the REST API.

regarding point 4, i am going to test it this weekend and come back to you with more details

Something I realized regarding (4) is that if the addon were re-written as a HA integration then it should be able to tell if its part of a supervised or core install. For a core install it can use the websockets API to manage backups and for a supervised install it could call the supervisor api. IIRC, the supervisor provides a proxy to allow Home Assistant core to access the supervisor API, for example to render the Backups and Addons page in the HA UI. That resolves the issue as far as I'm concerned.

A user would install a separate container, just not by using the supervisor addon store.

Home assistant doesn't install integrations in a separate container the way a supervised installation installs addons. To get the functionality of the addon in a non-supervised installation it would need to be re-written as a Home Assistant integration.

And that is all the good news. I've done a little digging into how HA integrations are written, and there would be two large chunks of work to make this addon an integration:

1. Move the addon's codebase into a PyPl project that could be imported into HA as an integration.
2. Rewrite the addon UI as part of the frontend project.

While still a substantial amount of work (1) could be accomplished with a few days of focused effort. The addon right now is designed to work inside a docker container, but its the same flavor of asynchronous python that Home Assistant uses natively so making the backend run inside of HA's framework wouldn't be too difficult. I'm sure there are some pain points I'm missing with this but it is very feasible.

(2) would be substantially more work. I'd estimate at least a month of focused effort and most likely more. Unless an integration has a dead-simple UI, its UI logic must be implemented as part of the frontend project, similar to how these integrations do it. The HA frontend doesn't have a way for integrations to "import" complicated UI logic from an external project. This has a couple of important ramifications:

1. The addon's UI would need to be completely re-written. The HA frontend uses a LitElement/Polymer/Typescript architecture that is incompatible with how the addon is currently written (using pure JS/Jinja2/JQuery). I don't think there is any way to get around a complete re-write.
2. All of the addon's substantial UI logic would be in the HA frontend project. This would make the Home Assistant Team responsible for maintaining the UI, and they are justifiably hesitant to accept responsibility for new codebases. Adding this to the frontend project would need to happen with their coordination, consideration and blessing. Any changes to the UI in the future would be gatekept by them, and at least the initial development would all need to be reviewed by them.

So as far as a plan for executing on this vision goes, I think here would be the steps:

1. Stop development, except perhaps for bugfixes, on the current supervisor based addon-in-a-container.
2. Abstract all the addon's dependencies on the supervisor (managing/creating snapshots, reading/writing config) in a way that lets me swap it out for functionality that HA core provides, then move this code into a PyPl project that Home Assistant could import.
3. Solicit the frontend team for advice/permission for how to add a bunch of new logic into the frontend project without overburdening them now or in the future.
4. Rewrite the entire addon UI in the HA frontend project.
5. In parallel, write the addon integration with hooks into Home assistant instead of the supervisor.
6. Once the integration is finished and working, make an announcement in the container version of the addon saying it now deprecated and you should install the integration version.

Assuming the HA Core and Frontend teams don't object to adding this functionality into their projects, I think this a feasible plan. The problem is still time. When I first started this addon 3 years ago I was in a place were I could dedicate all of my time to it for 2 months to get the first version out, then spend another month fixing bugs and adding the most requested features. Since then life's demands have grown and I maintain the project by fixing any bugs, supporting significant changes in HA's architecture, and sometimes implementing smaller features when I have the spare time. I have had some substantial contributions from helpful users over the years, but 95% of the addon is written and maintained by only me. At present I simply don't have the ability to dedicate a large percentage of my time to a rewrite, and then another few weeks fixing the bugs introduced either from my own re-implementation or from the HA team refining their initial implementation of HA Core backup. This will continue to be the case as long as I'm the primary maintainer, which is unlikely to change at any point unless I find someone who really wants to step up.

The addon is in a very stable place right now, with no outstanding bugs of consequence, and so I am also hesitant to make changes that jeopardize the stability of a project with such an "install and forget" userbase. "Stability" is kind of this project's brand.

If I were starting the project from scratch right now, I would go with building it as an integration instead of an addon. In that sense I'd like to make progress toward moving the project the in that direction so I'm making a new issue category called "Long term goals" that this issue will fall in to. When I am able to dedicate the time and effort, or when someone else wants to take up the challenge, this is one of the things to focus on. I'll start this by making an issue in the HA frontend asking how they'd recommend I approach adding this kind of project to their codebase.

[Citrowallon]

some news?

[hugo-leij]

Is there an update on this feature?

[merket]

Just wanna echo my +1 on the whole subject and thank everyone who is contributing.

[smartVanture]

Same here! Always loved your work thus was happy to donate and now really would love to have the possibility to implement it as a standalone container. Especially since HA stopped working through portainer I saw myself forced to convert to Home Assistant container.

[rodrigosiviero]

+1

[redlefloh]

+1

[labaland]

+1

[ctml91]

Does anyone know of an alternative method to do cloud backups for HA container?

[csobrinho]

For Hassio you have the Google drive plugin that works really well, for Kubernetes you have velero or some other backup option. For docker in general you have other backup options with snapshots. If running inside a VM then use the VM snapshot backup. For longhorn or ceph you also have a local backup or S3 compliant backup.