you say it still works with core in a venv?
on my test system with HAOS it doesn’t work in an automation:
Action backup.create not found
works after changing to action “hassio.backup_full”
have not yet updated my main environment, that’s the installation with core in the venv, will check again after I have updated in the coming days.
I totally appreciate what all the Devs do, but the irony is not lost on me that this release came out at the same time of “listening to our community” survey.
The two things are contradictory.
I don’t know why there is so much arguing about this. This is obviously done, by my opinion, for haos and to get people to use nabu casa. I didn’t enabled it yet as I’m using duplicati for my containers backup. Backups are stored on different ssd and everything is fine. And I’m using nabu casa for remote access regardless.
But this might not be a bad solution if you want to have a backup on different location, just in case.
You also said that it won’t stay forever and will be deprecated and removed in the future
Only automatic backup not manual?
What not let us do local/NAS backup without encryption? And why not mandatory encryption for Nabu casa cloud if you want (won’t be using it)
A great man once said, “If your not first, your last” 
You can do that. I’m using this for some time, but with encryption. maybe you can’t do this in haos but there are other types of installation.
What alternative is there that is not a total geek thing with command lines and git versioning on a server. The use of backups is a simple solution that both covers the disaster recovery, and recovery of individual files in a backup that is not from yesterday but from last week or last month.
Remember that all the devoloper needs to do to fix this is to make the encryption optional. In the UI it is a checkmark and the code must be a simple “if” to only include the password if the checkmark is set. We have learned the past days that the backup code still allows unencrypted backups (that was not clear the first days) so it must be a low hanging fruit to meet the demand from so many.
I must say that I understand that Nabu Casa will need to demand encrypted uploads for legal reasons. It removes a lot of legal liability within EU to have that. So it will be fully understandable that the use of Nabu Casa backup will require encryption. But then please allow manual overwrite to a key that a human can actually remember.
It is a problem, that it is dependent on the installation type of HA. I’m running my installation as a docker container, which is a supported installation and in this installation it works.
It will be removed with 2025.1.1… Remove backup toggle from supervisor addon page when update available by bramkragten · Pull Request #23602 · home-assistant/frontend · GitHub
Not sure I’m the best person to ask cause my solution is a total geek thing with command lines and git versioning on a server…
But, there are so many much more complex add-ons and integrations built by the community that solve a lot less important problems…
Here’s one non-geeky way: Whenever I go to edit a .yaml file, I’ll save a copy of the old one on my laptop, in a directory named “Old Config Files.”
Not that anyone asked, but this is also why I prefer YAML configuration, rather than UI only. In the UI, you can’t save archival copies of previous settings, or add comments about why you made those settings for future reference.
Warning - long (and very ranty) post. All you TLDR people can just keep scrolling. Thank you.
I’ve held off on commenting until the actual Nabu Casa staff was involved in providing some feedback, if not justification for why this was done.
What stands out is a tone-deaf response to how you should not deploy breaking changes to existing functionality, then frame them as a new feature which “will continue to be improved according to feedback and usage over the releases”:
Those who have been around for more than a year are starting to see a pattern where a decision is taken behind closed doors, then all the user feedback in the world will not convince the powers-that-be not to deploy it.
We’ve seen it happen with scan interval, weather forecasts, badges and now, backups. Each time there was vocal opposition during the beta phase. People tried to warn the devs in discord, github and on this very forum before the changes were released. They were consistently dismissed and ignored.
It’s like deja-vu all over again, but given the fact this is becoming an obvious pattern even more so in the past year makes it worrying for all users, not just the ones who have been around long enough.
People with more eloquence and experience than me have already explained that this is not what MVP is about. MVP only really applies to absolutely brand new features which do not impinge on existing functionality.
Changing something as fundamental as backup (formerly known as snapshots) which existed since before year.month versioning was introduced does not qualify as a new feature.
There are multiple red flags with that part of the message.
Yes, some of us have been here long enough to remember all these breaking changes framed as improvements. Others are still suffering the consequences of those changes (I hear card-mod just broke while trying to make badges customisable again. Remind me how “beautiful” that particular clusterfudge was please).
The “listen to feedback” part worries me too. We just replied to a survey in the past month, asking us what we think about HA’s values and commitment to privacy, sustainability, and choice (my emphasis).
Instead of being asked whether I would like my backups encrypted by default, with no easy option to opt-out or decrypt them, I was asked what gender I identify as and what religion I ascribe to.
The “it’s not us vs them situation” part worries me too, because it sure as hell starting to feel this way. Unless whoever calls the shots starts listening to genuine concerns before changes to existing functionality are rolled out, then people would be right in assuming there is actually an us vs them mentality.
Yes, which is why historically, the January release was either entirely skipped, or else extremely limited in scope in the past couple of years.
What follows, however, is the most tone-deaf part of the staff replies:
Honestly, why are these questions being asked now, after the release? Shouldn’t they have been asked before such a breaking backward-incompatible change? Like, you know, as part of the survey?
Also, they are entirely irrelevant. Like others have said, just because you never needed your seatbelts or airbags in the past doesn’t mean you don’t need them to work without any extra intervention on your part sometime in the future.
Great, so let’s just frame the fact that the downstream integrations haven’t caught up (yet) as something which should be applauded. Giving back the choice to do something as fundamental as an unencrypted backup “over the coming releases” doesn’t really cut it.
In the meantime, we’ll have to create yet another automation in order to restore functionality which we had out of the box a week ago. At this point, we should be used to it I guess.
I don’t wanna make an argument start, but wouldn’t the choice be “hey don’t agree with the current state of our built-in backup option? Thats ok! You’re free to use the other backup integrations. That’s your choice to make and we aren’t stopping you”. AutoBackup for instance just updated this morning to take advantage of the backup updates and mentioned planning to iterate to offer more advanced features.
It feels to me that the removing of backups before updates is not a backwards compatible change. Before we could check or uncheck the box. Now, we cannot do it without going through a separate process. This is a big deal for me. I the past I have always been comfortable implementing an update because I knew there was a backup. Going forward I will be hesitant to take updates.
This.
We now have many many folks uncovered in incremental who THOUGHT they were covered with backups. The process always did an incremental and even the code owners relied o it (see the breaking change notice for Z2M2. 0)
And then thodr same users had to enter into Z2M 2.0.
If like me they did it AFTER doing 2025.1 guess what didn’t happen (unless you manually did it yourself)
I hope they didn’t need a…
Whoops. Then all the issues with the 2.0 container…
Lucky is the only word that comes to mind. Disasterous could have been the word of the day.
I’ve been using version control software for… closing in on three decades, probably. It’s one of the pillars of software development. I’ve used everything from rcs, cvs, vss, subversion, and obviously been using Git daily for my professional life for… basically forever now. Including advanced usecases like splitting up and recombining repositories with history rewriting and whatnot.
I wouldn’t want to use version control software for my HA setup, it’s unnecessary complexity for my needs - backups (especially if I can go in and extract a few pieces of data) work just fine.
And I sure as hell wouldn’t want to impose a version control system, even with nice porcelain on top, to regular users.
That seems extremely ill-advised.
Why is pre-update backup functionality being removed? It’s such an obviously useful feature to have, considering that updates (as evidenced by this thread…) is one of the most likely ways to mess up your HA install.
Really? That’s such a lame excuse that I’m sick of hearing from development teams who make changes that, at best, are unpopular. Of course we don’t HAVE to upgrade, but the choice is between 1) accepting what you don’t want to remain up to date on something many of us have invested a great deal of time and money into, or 2) being left behind and becoming irrelevant in the scheme of things. Not much of a choice IMO (and I think you know that).
Also, I think it is important to remind “contributors” that, although we are ALL EXTREMELY GRATEFUL for their contributions to HA, there are, innumerably, more of us (users) than there are of you. Just because the relatively few of you (who are also many of the beta testers) think something is awesome, the rest of us may not. A good example is Madelena asking us NOW to tell you what we like or don’t like, and why - after the fact.
Most updates and improvements are pulled off without a hitch, and we all thank you tremendously. I think we all get the team’s excitement around automatic backups, and they are a fantastic feature to have, and we even get the need for encryption for anything going to the cloud, but… perhaps the rest of it wasn’t thought through quite as thoroughly as it should have been. Maybe it WAS due to the holidays, and if so, perhaps it is a lesson learned for all. Cheers, and long live HA!
It would seem, if my knowledge and logic is correct, that if you can no longer dive into and parse your .tar to pull out the working copy of a particular config file to replace the offending one, then there is no need for such pre-update functionality.
Plus, now you have 30 backups from the last 24 hours in the cloud that you can just restore and be right as rain, right? (assuming you have the encryption key).
All of THIS! 
I used to actively participate in the beta channel, but abandoned it when it became clear that unless you were a contributor (or other well-known entity), your opinion didn’t matter. That was way back when one person decided that the way many of us used the old History format as a status board no longer mattered, and wasn’t worth a simple check box user option. That was the point at which I became a HA consumer and stopped my monthly contributions to HA developers. I skip most updates now; only last week going from 2024.7 to 2024.12.5. It works for me.
The backup before update is the main thing I’m unhappy about.
Sure I can trigger my own backups whenever I want. But now I have to ensure I do it before I do any updates.
I’m sorry but it’s naivety that home assistant is stable enough to remove this functionality, if anything it’s getting less stable every release.
I’ve had home assistant running for many years, and never went near a backup until the past year. But recent releases have proved troublesome until their final release.
I could not say it better! THANK YOU!