In V2025.x, what happened to the option to create a backup before installing an update? Is there a config option to re-enable the option? I always back up before installing an update. If this was intentionally removed, I’d like to hear the (ill)logic behind that decision.
It’s been removed. Have a look here:
Thanks. From reading further, it appears this and forced encryption have caused quite a storm, and deservedly so.
Not sure what in the hell they are thinking!
So I posted a reply on someone’s github report about this issue, (now been closed, link below).
Where my understanding of the answer provided appears to suggest the old system wasn’t 100%, and that there is no guarantee that they would cover all aspects of the addon so making a false sense of security.
Although it’s still currently present in the addon page itself but not for Core.
The other aspect listed was that some people were running out of space due to having these on the disk.
So given reading between the lines - it’s better to do full backups for every addon and that the size of a full vs partial backups, those people with space issues will be facing those issues so much earlier.
I get that the system might not have been perfect. But removing it, is a blunt solution, if its a concern to the dev’s, then please give a warning it might not contain everything when selected vs it’s removal.
For me at least this has worked perfectly and bailed me out of a number of issues in the past.
A lot of the other grief coming out of this update, like the fixed time (makes sense as its after a database clean up), and encryption (to support those with a sub, and to protect people’s data). I’m totally fine with all of that, it was clearly advertised and all makes sense.
The new interface is clear about what is what, which should have helped those having space issues and clarify what backups people have (so solving the space issue).
Having a data retention plan is great, and could have been extended to the addons (like keep the last 3 automatic partials for each addon).
The key point this brings up is why are partial backups not suitable? When does this happen, which add-on’s are causing issues in the past, if its specific one’s, then the addon needs to be resolved NOT the backup system.
The only time I can see an addon restore could get weird, is when there is a change in the database, then that addon needs to make it clear in its patch notes, that there is a risk, what it is doing, and how to backup and roll back in the event of a problem.
This does lead onto the other side of this issue, is with the updates and especially their patch notes, and how inconsistent they are presented across the addons. Today, of the 3 I have pending, Core links to the blog, Mosquitto and Openthread both lists a few changes but no link to their change logs.
Hacs on the other hand, all of them have detailed change lists and a direct links to their github change logs.
Another suggestion I did have was around the patching version numbers. So frame them so they have a consistent meaning.
e.g. Major.Minor/monthly.patches. - 2.2.3
Major update, changes the database or adds huge changes, where a full backup is a must to roll back. Do this with caution type thing.
Minor/Updates, these changes are to the code base, similar to monthly updates and most importantly does not modify the database and so a roll back can be done via a partial backup.
Patch updates… as per minor, they don’t change much just provide patching.
You could if needed enhance this, with a post fix code, so you could define the pre-release updates with this AND Critical (for example)- to indicate an urgent critical update.
With standard version number controls like this, then within the HA update page, these can be used as flags to show extra information like, “Please do a full update for the update”
This system might need further refinement, to cover more of the development cycles most people don’t see, but the concept of using that information to control what backups are suitable, and even automated to presented to the users the correct type of backup based on the agreed version number system.
Hopefully the dev’s will read this and hopefully this helps move forward from this place we are currently in.
They should at least put back this option for HA-related updates such as Core, OS or supervisor. IMO this is a huge mis-step, especially considering backups are the focus feature this month. While the devs can argue that automated backups are now offered, there’s not even a guarantee that the user has set it up before doing updates.
If there are disk space issues, warn the user in advance. If there are issues concerning what’s backed up and what’s not, be up front with the user about it.
Don’t get me wrong, I really appreciate the hard work put into this release, and I see this being helpful for beginners, but myself and other users already had backup jobs running nightly through automation, so it’s counter-intuitive to tout “automated backups” and then remove the one feature that now requires me to manually back up first!