Before it took about 50 minutes to create a backup (3gb) with an automation:
Now it takes almost 2 hours. Is this because of encryption? I’m on a raspberry pi 4 running from SSD. Recorder stopped running, had to enable the recorder manually.
What I find somewhat surprising is that, despite many responses in this thread explicitly asking not to remove the “update before updating” option—and the team stating they value feedback and want to understand the community’s needs—a PR like this still gets merged
Perfect for causing data loss. What an excellent decision.
stating <> doing
and the team stating they value feedback
Yes, when its not too much criticism
I ran into this issue last night, when I needed to restore a file from a backup, just as I was about to hit the bed and had to get HA back up.
As you’ve mentioned, this is not a case that’s covered by having your config version controlled, as this is part of HA (HACS’s) internal storage files. Restoring from a backup is the only option.
Let’s talk about backups. Let’s be honest: they’re one of the most important yet often overlooked tasks. But when disaster strikes, like a hardware failure, having a reliable backup can save the day. Wouldn’t you love to be back up and running after disaster strikes?
I cannot help to emphasise the massive irony here, reading about the backup fiasco. Here is a real-life incident where less technically inclined users that have upgraded to 2025.1 with (possibly) their only backup being an encrypted one, could’ve been stuck.
I hope this is a lesson learnt.
And before this issue gets conflated by someone: This has nothing to do with the fact that it’s related to HACS. This could’ve happened to anything directly managed by HA.
I’m one of the people saying this and seeing this PR being merged feels like a punch in the guts. There has been no response on this specific subject and then this PR. Anyone saying that the community is being heard is obviously not telling the truth. Removing this option is stupid and a huge potential cause for data loss.
Where I live we have a saying that translates to “speaking with your wallet”. I currently have a NC subscription for the sole purpose of supporting the Home Assistant project, I don’t use any of the benefits that comes with the subscription. I’m seriously considering to cancel my NC subscription, maybe that is feedback they do understand.
WTH? Odd move.
I didn’t renew my Nabu Casa subscription in 2024 and was thinking about doing so at the beginning of 2025. I don’t really need it because I use Alexa and remote access in other ways. I was thinking about just continuing to support the project with my subscription.
Thank you for pointing out the PR. Maybe the problem is with me and I’m not able to understand the PR and a developer will comment on what it means. Until then, I definitely won’t renew (and of course not until native backups are supported without encryption).
Like others, I’ve seen more than one error that a backup could not be uploaded. to the cloud. I suspect this is the understandable result of creating all the backups in a single timezone at the same time and overloading the server, though I can not be certain of course.
There doesn’t seem to be a way to upload a backup to the NC cloud manually, not from HA and not from the web interface either.
I’m a big fan of HA and want to congratulate the team for this next feature rich update!
That said, I had to realize that this is the second or third update without a a single bigger headline that interests me. We do not use Assist, I don’t use the UI for automations or helpers, I did not yet switch to the new generation of UI elements, and I have a well working backup strategy using rclone.
Thinking about what that means:
The Victron repo is not really maintained anymore ( https://github.com/sfstar/hass-victron). Check the new one: ( https://github.com/remcom/hass-victron)
I feel just the opposite…
I do want to keep my NC subscription. To support, and to be part of.
being part of, also means being influential. Even minimal. Well, at least in regular life 
But I get it, one needs some confirmation now and then that feeling is mutual.
After the 2025.1 update restarts of Home Assistant take a very long time. It takes about 5 - 6 minutes until I get the “everything up and running again” message (with 2024.12.5 is was in the seconds, far too fast to be of any concern). The hold up seems to be my configuration.yaml. All my custom template sensors in the configuration.yaml are unavailable until the before mentioned message appears. Unfortunately I haven’t seen any mention of this so it is probably caused by my specific configuration. Any hints what I should be looking at?
Removing the backup toggle is a real nuicense. This is gonna cause so much trouble.
For me, I’d say that this is worse than the encryption issue - at lease I can continue to use Google Drive Backup.
Yes but apparently we’re too stupid to manage our own backups and prevent them filling up the disk. As the new system has no way of cleaning up after these add-on update / core update backups.
Logs might be a good start
especially on the templates if you already suspect anything there
could also be another entity from some integration which you use in those templates
I’m betting on a slow integration using the old blocking calls. There will be warnings or errors in your logs about this.
Thanks for your suggestion. I looked at the logs and found this:
2025-01-07 13:10:19.836 WARNING (MainThread) [homeassistant.bootstrap] Setup timed out for bootstrap waiting on {<Task pending name=‘Task-566’ coro=<MySkodaDataUpdateCoordinator._mqtt_connect() running at /config/custom_components/myskoda/coordinator.py:180> wait_for= cb=[set.remove()]>} - moving forward
I deactivated the integration and now HA restarts are as quickly as before. Thanks!
OK, so I was debating chiming in here or not, as this thread is already cray-cray. But I have a rule about not letting brave people stand alone or feel unappreciated, so I needed to voice my support for all the work that @tom_l and @ShadowFist have done in this thread and for their other contributions such as during beta rounds; your efforts may not be celebrated but they sure as heck are appreciated by a great many people, so thank you. 
After that intro, let’s cut to the chase…
I may not be a backup expert, or a code expert, and my HA install is rudimentary at best. But what I am expert at is Agile methodologies, Product Ownership and leading development teams. And I can tell you that description is NOT best practice, and it is 100% NOT what MVP is about.
The principle of MVP is “what is the least/cheapest amount of work we can do to run an experiment that we can learn something from”. Examples of cheap things include interviews with ‘friendlies’ or subject matter experts, surveys and questionnaires, low-fidelity mockups. Slightly more expensive options are conceptual or functional prototypes, usability tests, competitor analysis. But the MOST expensive option? Code! It needs to be architected, designed, written, reviewed, unit tested, regression tested, with branches, merges, backouts and pull requests. Even after all that it needs have release notes and instructions written and support docs updated. But that’s just the beginning because - if you use code to release an MVP to test a hypothesis with a foundation concept that’s wrong - you then need to spend lots more time dealing with a 600-post thread and a community backlash.
NC could have just asked the questions from your post in a dedicated survey thread to get the same answers without all this drama and wasted time, so that was a major mis-step that I hope the team has learned from.
From what I’ve read in this thread the other major error seems to be that there was even a beta test where the same feedback was given. I’m puzzled as to why NC would go to the trouble of having a beta group if it wasn’t going to listen to the feedback? Those beta testers are end-users, so their opinions should be like gold. And if NC disagrees with those kind beta-testing end-users then that’s the perfect time and reason to then run surveys and other low-cost tests with a wider sample size and audience to see which approach is right.
I hope this is the last time this sort of thing happens, as the user-base here is exceptional and their voices should be valued and listened to, and their time and expertise should be respected and leveraged like the brilliant tools that they are.
tl;dr: “MVP” is for testing hypotheses with a subset of users in a safe and non-destructive way. It should never be used for directional shifts in a live product’s foundation concepts that will impact 100% of the user-base.
