So I’m updating from 2025.1.0 to 2025.1.1 and I noticed there is no longer a toggle to create a backup before the update! Is this a bug?
no. it’s the new feature 
So called MVP 
11 Likes
There is ZERO logic to this. I thought this update was all about making backups easier. Don’t get me wrong, I love all the new stuff but now I have to take extra steps to create a backup before an update? This has to be a mistake! I get we have automatic backups everyday now, but what about the changes I’ve made in the last 13 hours since the automatic backup. I’m just supposed to lose all that now if I need to revert.
EDIT: So, as it turns out, there IS logic to this, but you need to be aware of things like DB migration for this to work! (DB migration would still require a backup to restore from)
3 Likes
I never called myself an MVP
It was also simply a mess of backups for individual add-ons. Most of which don’t need to be backed up when a re-install is just as fast. Though I do see the convenience of restoring a full backup and having all the add-ons there without needing to remember them when say, migrating to a new system. In which case all those little backups per update become useless.
Really if updating something like File Editor happens to go bad and breaks it, I can restore the single add-on from a full backup. There isn’t really “data” there that is of need which makes it require its own separate backup. It’s the same for a majority of add-ons (at least the ones I use myself).
So I don’t need 12 old copies of the file editor add-on sitting there in whatever location. Now do this for 10 other add-ons…
(I don’t use File Editor, just an example)
I think most people were oblivious to this and kept the toggle active. I did the exact opposite. Even for HA Core update because I already have scheduled full backups, I don’t need to waste the time backing up HA Core because I can easily roll back to the previous version using ha core update --version=2025.4.3 and going through the motions of restoring a backup is not needed.
Google Drive Add-on is great for offering all of these auto-management options for this reason.
So that leaves: How to make it so that more significant add-ons with actual time-sensitive data like Mariadb or Influxdb actually have the data they had 5 minutes ago and not the data from yesterday or 8 hours ago?
Or, alternatively, how can we make it so that add-ons can be rolled back just like HA can? Why do they rely on a backup to get to a previous version?
Maybe this could be set on the add-on configuration page with another toggle: “Backup before update” and it wouldn’t come into the backup plan at all. The add-on itself determines it? I don’t know. There’s likely a good way and a bad way which still needs to be evaluated.
I’ve seen many people in Discord not realize that the HA core “backup before updating” only backed up Core. Now they have this single backup of HA Core. They want their whole system back on a new machine and never really thought about it. All they saved was the one backup which appeared to be the biggest and made an assumption or something. For whatever reason they now only have /config and that is all.
And I can rationalize that HA (the server, not the organization) should absolutely not encourage the copying and distribution of unsecure backups to any cloud service, regardless of personal preference. And there’s no way to know that a NAS is truly local. So I’m fine with the UI offering an encrypted backup strategy, and if an un-encrypted backup is desired, simply create it in an automation using hassio.backup_full or _partial. It’s not like the weather forecast change. It’s straightforward to set up, and can be triggered by anything you can come up with.
There are countless other way to make backups using add-ons or custom integrations, including within HA itself, which never encrypted by default. Having one option that does isn’t breaking anything here.
My main pain points:
- An easy way to trigger a backup before an update for an add-on that needs it.
- It would be nice if commonly used tools which everyone already has such as 7zip etc didn’t choke with a
securetararchive.
13 Likes
This was easily avoided and easily solvable.
Put the check box back and when I do it don’t encrypt it. Make it work EXACTLY HOW IT WORKED before. Heck I’d even take default off to the backup. But gone is a HUGE problem. (im holding my 2025.1.1 point release because of that horrid little PR. And losing the last checkbox)
Then ad a second UI entry next to it that says super cool new TEST backup and have it do whatever the heck it wants.
10 Likes
Interesting, I didn’t think it worked like that. How often is it this simple? For example when we had the database update… Wouldn’t you need to have backup to restore from, or would the database downgrade when installing the older version. I get things like that doesn’t happen often, which is why I’m asking.
For what it’s worth, I’ve never restored a backup because of that function. You can’t do this when there’s a DB migration though.
5 Likes
Yeah, staying aware of db changes is needed for this, though it’s never been an issue for me.
1 Like
The only “good way” is to simply restore the button and let the users make their choices. Period. Who’s to say if add-on a " has important data which should be backed up", whereas add-on b “is fine even if it breaks”? This is ridiculous. A problem was created out of nowhere. And literally no one asked for that change, nor was there ever a true need for it. This is everybody’s waste of time.
7 Likes
Reinstalling of the whole system is not so fast. It causes an outage. I know you might think that HA is a toy of bored males. But it’s not. It’s the system with certain availability required.
Also, why the heck should I spend on it more time, getting longer outage and lost more data if it can be done in shorter period of time?
yeah… Especially if data migration was involved into upgrade. I wish you luck to roll back this way.
Then you should look around before you make such statements.
Not sure what does it mean. That because you have such preferences, other have no right to work their way?
And it’s not your business.
While copying to NAS or other location, encrypted or not, should be still user’s decision, the discussion is about local backups.
Encrypt during data transfer to cloud or whatever (integration should care about that). Not during backup creation.
11 Likes
I appreciate the idea of the backup solution. However, I have two questions:
- Why not allow users to set their own backup times? For instance, what if I work at a petrol station or in a bakery and have to wake up early? And If I back up my data to your Cloud: do you want to receive all backups simultaneously?
- Why not permit backups at user-defined intervals? Currently, I back up my system every three days (nights) since I don’t make many changes to warrant daily backupsI would like to have options such as: every n days, Monday and Wednesday, first of the month, the 15th of the month, at self-defined times.
Just like a normal backup 
3 Likes
@cogneato and @petro - This is great to know, thank you! It makes much more sense (to me, anyway) why the toggle was removed now.
I hated that toggle and remember when there was no such option. 
Make it a button that kicks off a backup, if anything.
1 Like
That’s funny 
1 Like
I can sort of see the reasoning of the devs here- there already are a load of “batch jobs” in HA that fire at set times outside of peak (local TZ) hours.
If the database cleanup script fires at 04:00 (and has done for years - you just haven’t noticed…), the backup firing at 04:45 is the least of your issues in a nocturnal use-case.
The ability to set “out of hours” is a different but valid feature request.
1 Like
I was referring specifically to reinstalling a single add-on and one which does not have much going on aside from basic configuration. SSH, Samba, Mosquitto broker, Piper, Tailscale…There are many and I don’t need up to the minute, right before the update, backup clutter of these. I can pull previous versions from my full backup.
You weren’t using it your way. You were using a way that was added at some point by someone else. You were then using their way.
And this is an easy one to reverse.: Because many found some solace in it, I had to as well? Pshh.
It was a toggle. It was annoying. Make it a button that you have to push and I don’t.
It’s in HA’s best interest to offer a simple, secure, set-it-and-go method of making a backup and distributing it for people who don’t have advanced setups.
I didn’t like it in the first 5 minutes of using it. I like it now. What are you going to blast me for? Liking it?
There are a hundred different ways to copy everything already. Simply drag a folder from one network share to another. Boom. Unencrypted backup of that folder. That’s literally how the first HA backups were handled. That or any other more sophisticated way you can come up with of copying your stuff is not my business. If secure backups cause grief use FTP. Use rsync. Use your own automation.
People were upset when authentication was first added to HA. Like, having a user and password…at all. You could use the same argument “It’s local and not your business”. Well, yeah until people start exposing their instance to the internet and then the next security audit comes along. Then suddenly everything is HA’s fault!
It does no harm to have HA suggest a secure method as a default. It isn’t taking away your right or ability or even convenience to do things insecurely, as many other options exist and are well established.
4 Likes
As arganto said. Please!