Ive NEEDED to restore at least three times in 1.5 years. Wanted to - never. I’m also a weird bird who practices disaster recovery.
One of those was the Node red v. 16 issue which if I had not been able to open the archive I’d have been absolutely and utterly boned.
The backup being an unencrypted tarball of the entire config folder is the single most useful source for older copies of your config. Period. I rely on it staying that way.
Update the backup PROCESS all you want and enforce encryption when storing to cloud fine. But leave my files alone and unencrypted on MY box.
Also Z2M needs to update its update page.
It denoted if you install it it will autobackup and. You should keep it in case you need to roll back.
After 2025.1 this is not true?
Autobackup and unlock my backup immediately please. (oh and I didn’t forget my popcorn)
My primary use case would be the moment I want to restore my backup because I had some sort of system failure and I don’t have the key anymore. That is the most important one. I only learned during the beta that it is possible to go into your .tar archives. That could have saved me a few restores and lost data.
I didn’t keep track but I think I restored backups about 10-15 times last year. I tinker. I beta test with my production system. I usually backup before I do something stupid. Stuff goes wrong, I restore.
I know the beta was over the holidays. But the feedback about encryption being mandatory was very clear and loud in the discord. I can understand that you could not fix this immediately. What I find difficult to understand is
a) Homeassistant has choice as one of its leading principles. How can it be that NOT giving your users this simple choice was thought to be in line with that principle?
b) Why did you not anticipate that the rest of the community’s feedback would be in line with the beta testers? Adding a few lines to the release notes explaining that you realize it was an oversight and are working on a solution for this would have done a lot.
Having been on the beta test team for a year or so now, I have the feeling that the beta period is simply too short. I think if the beta period was a month rather than a week it could be much more effective and more people would join as well.
I have not installed this release yet. But I am wondering why we can’t create a script / automation that runs after the backup and decrypts the local copy? We would have to hard code the key in it. But it would result in having a locally unencrypted version. What am I missing?
Once every month or two. It depends how active I have been re-configuring things and if those things need reverting.
To do minor YAML configuration reversions with copy (from backup yaml files) and paste (to configuration.yaml or included files) without the need to restore the entire backup. A reload is usually sufficient after this, worst case a restart.
I keep 30 backups on my NAS as there is plenty of space available there. And I have needed to go back that far at least once. Locally (on system) I only keep 7 backups.
Very, very rarely. Usually the above copy/paste is sufficient or worst case a rollback of core version using the CLI when beta testing goes wrong, this negates the need for a full restore with subsequent data loss (that would happen between backup creation time and restore time).
I think I have used the full backup restore feature 3 times in the last 7 years. Twice for moving to new hardware and once for a major HA OS update fail.
Partial restore is however useful for restoring add-ons to previous versions when updates do not go as planned. Like the V2.01 Zigbee2Mqtt add-on update I did today.
Being able to easily back up add-ons at the time they were updated was an extremely useful feature and minimised data loss for add-ons like MariaDB and InfluxDB. Now the process to create a manual partial backup before updating an addon is much less user friendly.
Likewise the ability to create a backup before a core update would minimise data loss for those users using the default database.
Here is another problem:
If I use my sambra to copy over to my storage area and then delete the files from the backup folder on the HA. The database still shows all the old files there but they are not. So there has to be away to update/refresh the database for the new automated back system.
A reboot does not update the database.
Huh. Yeah the refresh button has gone from the overflow menu. Hopefully this is not required when uploading a backup (it used to be needed). I’m not in a position to test this atm.
Forcing backup encryption in fact feels overreaching. I’m all for security and have encrypted my backups from early on, besides storing them on encrypted storage too. But even enterprise-level backup or storage platforms do not force encryption by default. Heck, even Windows doesn’t force you to enable BitLocker.
Probably related to the “Farewell to the following” section where it says: * DTE Energy Bridge has been removed after being deprecated. The integration was no longer functional.
HACS add-ons are maintained by individual contributors- NOT Nabu Casa. You can’t expect them to test the hundreds of integrations on HACS.
That there are so many integrations in HACS is the blessing of open source.
That there are so many contributors to the project is the curse of open source.
If an update to Home Assistant breaks a HACS integration that you use, then your issue is with the integration author. Not Nabu Casa.
I don´t mind regarding backups encryption, I know they will solve it in the future updates, and I´m also using another methods, like proxmox backup or google drive addon. I can wait.
In the other points, do you recommend to update the version now, or wait for the x.1 ?. any important blcoeked proves more than published in the release?
Ignoring the extensive push back you had during beta (makes me wonder what the purpose of beta is if you ignore feedback!).
And as for the excuse that beta was over the busy holiday season, why push such a fundamental change at such a time?
I strongly disagree with the concept of pushing a fundamental change and then asking for feedback. That is simply the wrong way round.
And before you say that it is not a fundamental change, changing from a model that promotes choice to this fiasco is a substantial change in philosophy. And removing the ability to easily backup an addon before updating it is a pretty fundamental change. And at the same time z2m releases 2.0. Oh well done! Very clever.
Also the fact that no developers or team members have posted in response to the clearly unhappy feedback says more than your promise of responses to feedback.
Even your response lacks detail. When will there be control over the ability to enable/disable encryption? Just give us an answer, please.