I would be too if I still lived on the West Coast. It is fun to browse what may be on the market in the next few years.
Maybe a small thing but since 2024.11 manual backup names are lost if created with dots in the name, f.e. âFull_2024.12.5â displayed with empty name in the Backups listâŚ
Hope this works now but decided to wait for later 2025.1.x version before upgrade.
Iâve version-pinned the Android app for that very reason â still havenât made an account. Should probably make a backup of the .apk while I remember
I stand corrected, balloob / paulus has commented 36 minute before i postedâŚ
Youâre missing:
- Bad use of crypto (deriving IV from key, and more generally, that youâre rolling your own solution.)
- Padding potentially causing data corruption?
Actually, itâs only 3rd party software that has trouble reading the file. Decrypting via home assistant wonât have that problem. So there is no corruption, you just have to use the community script Tom L linked (at the moment).
Not defending anything, just clarifying that particular issue that was listed.
Yes.
You can still make a backup the manual way from developer tools or from an automation but it is obvious from reading between the lines of Frencks reply that it a matter of time before that goes away. All they offer is that we a UI in HA where we can pull out things from a backup. That is not good enough. If I have accidently goofed a config file that makes HA not start there is no UI. We need unencrypted local backups
EDIT. I am reading Paulus statement after I replied the above
Thanks for the response.
I think skipping a January release would be a fine idea. Gives everyone a break
Iâd also suggest that major deprecations are not removed until the Feb release as it seems this Jan release broke quite a few integrations and it isnât a great time of year to do that.
The issue here is that it wasnât absolutely clear that the âmandated encryptionâ only affected the new automated backup solution.
Iâll skip this Jan release and wait for the end of the Feb release cycle.
[edit]
You missed -
Forcing a specific time for a backup process. Perhaps add in configuring when the clean-up is done. You might not be busy between 4-5am, doesnât mean everyone isnât busy then.
My #1 issue is someone decided I donât need auto backup on upgrade. (on my completely non-custom non painstakingly built process) not just defaulted it Off⌠Got rid of it. And then put in an FR to remove it from the place that still had it when they realized they didnât kill it off completely.
Unacceptable. Thatâs when they stepped into breaking changes (and yes I still refuse whatever that idiot phrasing is.)
My question is rather simple: What is the official reasoning behind the removal of the backup switch before upgrades? I havenât seen one nor can I imagine one.
Saving disk space⌠Some users complained about running out of space.
And the only reason for a (presumable) lack of space for (some) users is this switch? Apart from that, backups before upgrades are only OPTIONAL, arenât they? Thatâs why there is this switch there, isnât it? If someone doesnât have enough space, they can just opt not to make a backup.
Basically. Yes.
When you hit the upgrade button there (pre 2025.1)is a little switch asking whether you wanted a backup. It was default on.
It was a no brainer to say upgrade Z2M because hey a backup is getting cut for just that addon and if I need to go back. Boom there it is.
Then Google drive and samba picked up and moved copies for me every night to archival.
Someone with low space can CONSCIOUSLY choose not to cut a backup. (your funeral - my spicy take is if you donât have enough space to backup you donât have enough space to run⌠But I digress)
Now if you want that same protection you need to Manually cut a backup before you update or you have to rollback to the last full backup. For me last night. For everyone else⌠Eh?
Or simply make off the default option and be done with that. The complete removal of the toggle though is at least unjustified and too much for me.
And thatâs the whole thing in a nutshell.
I can live with an MVP of the new cool year of backup (still prefer year of security⌠Make it happen) or whatever⌠BUT.
You do NOT EVER EVER jack with something as important as a backup without making it CRYSTAL CLEAR that you are testing. And making it 100% optional. (this is where devops and it ops people see things very differently⌠Im an IT Ops person)
The minute they modified the default UI and worse took out existing features people RELY ON thatâs when they lost me.
Test the new backup experience all you want just donât screw up my existing process for something so important as BACKUP while you do it.
Full stop.
I can think of two.
- Weâre automatically backing up nightly, so you donât need another one just before the upgrade.
or - This would fill our cloud servers too fast.
I hate to contradict you, but I donât think most people do have large complicated backup solutions that you have broken like you implying.
I would imagine most people have the complete opposite, an incredibly simple backup provided mainly by the updates back up switch, which you are removing.
People will then cherry pick from this backup file what to restore.
I appreciate you taking the time to respond, but I think a step back and re-approach to this is required.
I think a general rethink needs to go into the dev cycle as well, quality is been sacrificed for quantity which is never a good idea. It almost feels like you need to have a big announcement each month so push things through the cycle too quick. Iâve worked in many software companies whoâve gone down that rabbit whole ( agile, scrums, sprints etc donât work for quality ), and those that survived reverted that approach when they realised they sacrificed quality and customer satisfaction.
Youâve got an incredible knowledgeable community who are generally willing to help, but this and other releases recently seem to ignore that, Iâm glad your looking to address that in the beta stage, but I would advise earlier engagement at the design stage.
Apologies for being contrary here, but there was no automated backup before in the UI. It was prompt before any update. So why make an active decision to exclude the last place it was in the UI with 2025.1.1?
As I and others have asked before, please explain the rationale behind these new backup system decisions?
Itâs a cheap excuse.
If running out of space would be the real case, the HA team should provide a way (default) to better organize storage space.
The best practice is to split storage into more volumes: for the core system, for logs, for data, and for backups.
This way running out-of-space during backup (regular, or prior to update) wouldnât influence the system. The Solution for the problem.
Jeezus⌠so obvious. Itâs not rocket science.
I really donât believe they are serious with reasoning.
Itâs interesting that this is #5 on the list. And saying itâs only âsomeâ users seems to be dismissive of the majority of comments here.
The problem is NOT that a new feature was added. The automatic backups will be great for some people. Encryption will be great for some people. Nobody is arguing against those things.
The problem is that existing functionality was REMOVED. The ability to create unencrypted local backups, and the ability to back up with a simple check box when updating.
These are fundamental to the concerns being raised here. Side-stepping around those will not resolve those concerns.
It would be great if we had some firm direction as to whether or not allowing unencrypted local backups is part of the plan going forward. Itâs a very simple question, and one that I think deserves a direct answer.