Backup is absolutely key, and I also (so far) relied on 3rd party integrations.
Key is of course to back up to a totally different medium. It does not help to backup onto the same harddisk where the original system is on, when the disk itself might be subject to failure. Also, I’d like to avoid using another disk (SSD, whatever) attached to the same HA server when e.g. there is a flooding or other damage to the system itself, thus I am always doing backups to a physically different location.
I use so far Nextcloud as a potential target, i.e. having geo-redundant backup storage.
Key is also the Restore function - I hope that future releases also look at this, so an easy way of restoring an encrypted backup is part of an initial, maiden system startup…
Thx for the precious work on a highly-relevant topic - and a Happy New Year to you all!
To me it seems a bit risky updating. Will my current scheduled automatic backups to GDrive (the Add-on) continue to work as they do now if I don’t touch the new normal backups-system? If I can continue to use that without bothering with the new system then I might upgrade. Unrelated to backups, there are some users reporting issues with modbus, climate/smartir and HACS which also makes me a bit nervous.
This thread doesn’t need yet another ‘vote’ for unencrypted backups so I have held off.
What really staggers me though is despite this being just about the hottest topic I can remember over the last seven years, except perhaps a few years ago with the fears of yaml configuration going away or if I recall correctly MQTT being broken by an upgrade, is the complete lack of any communication from Nabu Casa except a slightly ridiculous, after the fact, request for information.
On the other hand I shouldn’t be staggerred, it is fairly par for the course with NC, one of the reasons I very reluctantly stopped my subscription. Everything that comes out of NC in the form of product/brand communication is exactly right and exactly what I want to hear and what I want to support.
It is some of what isn’t said and some of the actions that can be questionable.
But Petro is right, if you are commenting here the least you can do is give answers to the quetsions.
Not often, maybe one event a month or less. But that one event could mean opening it several times.
To extract individual bits of code or look at how something worked ‘before’. It is always to recover either an error (self inflicted) or to revert something because I realised the new way was not in fact such a good idea.
I think never.
And for the record I have a timed automation that calls hassio.backup_full.
So from what I’ve read I am going to be ok if I can pluck up the courage to upgrade - the card-mod issue is another big one for me though.
(EDIT: tom_l posted while I was posting. Seems I should be ok with that one too!)
(EDIT2: Maybe not…)
My backup strategy if you're interestedI have a `cmd` script using Robocopy that runs every time I start my PC (not the same machine that runs HA)
- It Deletes old backups (older than 8 days on the HA machine)
- Copies any new backups to a folder on my PC
- Copies my Packages folder to my PC after moving the existing Packages folder
- Does the same for python scripts, esphome yaml files and root config files
The entire HA backup folder on my PC is included in my scheduled backup to NAS job
This way I have 8 days of full backups as well as two days of plain text backups of all my yaml for much easier and quicker access.
On three different machines and off site too if I choose to include the backup folder as part of my OneDrive
except that fix introduces many more issues… also because of unannounced changes in several core frontend cards (that needed to be incorporated in the custom card-mod apparently).
fwiw, and awaiting true debugging time, there is also a small edit we can to to get card_mod up and running again.
this could have been communicated so much better, and would have, if the team truly felt it needed to known its user base, or whatever the title of that query was.
btw Tom, I’ve stopped using the word ‘Bug/issue’ here, because the stance of the team is this (custom stuff) is not supported anyway, and they see no need to inform their user base.
All open source and out in the open, so you can follow along in the GitHub, that is just about it.
Which ultimately is what makes using HA such a problematic thing if you need more than the basic options of unmodded core/frontend, and blindly update
Ah sorry, I was not aware there were still issues. I use card-mod themes for most styling (fairly extensive though) and only a few direct in card mods. I had no issue with them before or after the update.
as for the backup: I just had to revert a stupid yaml edit I did, and couldn’t undo, because I had closed the editor too soon…
had not yet manually saved all of my frontend locally over SMB, so had to lookup last nights backup. Only being reminded of the fact that these backups don’t have user-friendly names…
it would be so helpful if these would get the same names as in the UI, albeit with the date appended
yeah, well, they might not be ‘issues’ in the true sense of the GitHub meaning, but having to rewrite many configurations that have been functioning over the last few years does feel like that.
tbh, they might actually be issues in card-mod now, I am not even sure just yet, because not sure we can find the correct syntax.
Also, we are not allowed to discuss this in the beta channel, so even though I posted about it in the card-mod thread, many people not in #beta simply weren’t aware. And because of that are bitten upon release.
I want to address a few comments I’ve seen here. I won’t single them out, because I want this to be constructive, not a complaint.
The “official” response to the concerns about the new backup process was polite and to-the-point, which I appreciated. Asking for more information was a good first step. One question, however, got my attention.
I’ve worked in IT a long time, and I’ve been involved in development on lots of different projects. One of the things which I’ve learned is a very bad sign is when developers start asking customers “Why would you want to do that?”
Yes, I used the term “customer.” Whether it’s commercial, internal-use or open-source, development efforts are pointless if people don’t want to use the product. I’ve found it’s very helpful to get the development team accustomed to calling their users “customers,” even if they’re not actually paying.
I need to stop here and say that HA is a great project, with a skilled and dedicated team. It’s just that some of the signs are pointing in the wrong direction. I hope this concern is proven wrong.
Believe me, it feels much better to hear customers singing the praises of a new release which makes their lives easier, than b*tching when it goes the other way.
This is where I don’t agree. Surely a good first step would be to ask before delivering?
(Which is why I called it ‘slightly ridiculous’)
At least one comment here if I remember correctly said that the beta gave lots of feedback about the encryption issue but it appears if that was so, then it was ignored.
But I want to have both, storing on NAS and on local ‘disk’ as well, which Samba-Backup does automatically.
I want to have the possibility first to store/restore backups if NAS is not available.
Agreed, there should be an official statement in order to stop the encryption discussion here. Making faults is not that bad and can happen. I would love to give beta testers in future more voice heard. A lot of “hot” discussions after a release had also been “hot” discussions already during beta testing on discord. Beta testing time is short, which is not bad as many things get fixed very fast, but if big concerns are identified I would love hold back things in future.
On the whole discussion on broken changes and custom components.
I appreciate that the core developers cannot support or guarantee or even be aware of all the many custom components.
But there is something that can be done.
I was release manager for many years for the TWiki and later Foswiki open source projects (Perl). And they are systems with a strong plugin community as well. The plugins were very equivalents to integrations in Home Assistant.
The core team supported around 20 plugins which were distributed with Foswiki.
And then we had an official API which was a list of official function calls and an official data structure of the document object. These were considered holy. We did not change them ever. If we enhanced them we always made them backwards compatible. Only if a security issue was involved would be break things.
Most plugins used these APIs. And most plugins never broke for this reason. A number of plugins used non API function calls. Nothing prevented a plugin to do that. But the plugin author was on his/her own. No support. No pre-warnings. And as an admin user you quickly learned to steer clear of plugins that used non API calls which was easy to inspect in the code as all API calls had names that identified them as API.
Home Assistant should consider to better define API for integrations. Both the supported and the custom. And such API should include a subset of the CSS names so that things like colours of icons etc have names that never ever will be changed. If you mod beyond the API you ask for trouble.
I’ve only used it to migrate to new hardware in recent times.
However,
I am ultra cautious on installing updates - never pull in a ‘.0’ update (or only if I am super sure of it, or it has been out for a couple of months).
Last time I restored, I did it for a single add-on.
I do have a backup strategy that has 7 days & 3 weekly (for when you don’t notice something has broken immediately). Held in differing locations (local, local NAS, cloud).
Encryption of Backups: Apologies, but when such significant changes are made, backward compatibility must be ensured over several releases. And features like encryption should be optional and configurable by the user, allowing them to be enabled or disabled.
Why is encryption mandatory? Is the ‘Home Assistant Cloud’ not secure?
Every user should be able to decide for themselves whether and how to encrypt their data…
