Running ha backups reload
fixed this.
Same problem
You have to admit âusername checks outâ
Have you actually read the thread before posting?
Victron is custom - talk to the developer, via their github.
Briefly but admittedly not thoroughly. But dually noted. I reverted to previous release anyway and solved the issue so all good. Wasnât complaining, more so just bringing it to attention but thanks for letting me know proper procedure.
Itâs still possible to name the backups in 2025.1. But it takes more steps.
- click âbackup nowâ
- click âmanual backupâ
- select backup content
- click ânextâ
- Enter a name in the ânameâ field
- click âcreate backupâ
For better understanding one must ask the right questionsâŚ
Is it really only half-baked or could there be a deeper purpouse of recent changes, which feel somewhat unnecessary?
Forced encryption is annoying for sure, but itâs actually not that bad. The really bad part comes from system-generated keys and the removal of users ability to set individual passwords of free choice. Do you consider your operating system trustworthy enough to never leak those keys, potentially enabling certain entities to decrypt the cloud data?
Is there an interest in stripping users from their control over encryption and why could devs be implementing such questionable design changes?
To you. Others including myself think it is quite a bit more than âannoyingâ.
I use a local NAS as the backup target (mounted in HA with NFS) which then backs up to an offsite NAS. The NAS can have encrypted volumes or encrypted files (i.e. btrfs). I am able to determine where to encrypt my own data, I do not need HA deciding it knows whatâs best for my environment. And hereâs the thing: I get wanting to make an easy button for new users, but there is also a supporting base of installed users that have been with HA since the before times.
As far as when and how and when I might use a backup for: irrelevant. One reason we make backups, like other safety things in the world like seat belts or helmets, is for the unexpected and unplanned.
Making changes around a major holiday is also a choice. (hint: if someone has to bring up holidays as an excuse then just maybe it shouldnât have been released yet)
An alternate choice could be to take it easy around major holidays. Slow down, enjoy the time off with friends and family, only fix critical bugs, and give new stuff some more time when everyone is back to work. Maybe take that extra time to add a couple of those priority features that could make a new feature better instead of pushing out a âminimum viable productâ or whatever buzzwords fit.
Same Problem here, for 2 days now.
The repair message also states:
Further information can be found in the logs.
The only question is where?
There is nothing to be found in the logs from the Home Assistant Core, Supervisor and Host, and I cannot find an extra backup log.
I assume that the servers are overloaded, since it worked yesterday when the automatic backup was triggered manually and today:
Possibly too many people in one time zone in Europe for the servers?
Greetings from Germany
I find all the comments of âxxx is 3rd party contact the developersâ a bit condescending.
The fact that this release broke so many 3rd part integrations highlights a fundamental problem in this release doesnât it?
If it were a security issue it would be a different case.
But when you have so many people relying on 3rd party integrations itâs the reason why HA needs to make everything backwards compatible, itâs a necessary evil of making your system âopenâ.
Re: backups, it would be nice if there was an official response, which would hopefully stop the b*tching, hold the hands up, we made a booboo, working on it, would go a long way.
It is the only way to get these issues caused by depreciations fixed.
No. The depreciation that caused this has been giving you warnings for 6 months. It was up to you to contact the 3rd party developer about this. Or the developer to read the HA developers blog. A lot of these 3rd party integrations seem to have been abandoned though and your only options are to either stop using them or fork and fix them (or hope someone else does).
My nuc have been running HA 24/7 since around 2018. Not once since then have I needed a full backup. but many times have I needed to extract files from backups to fix my clumsy mistakes. I have the Google drive backup plugin set up just in case.
This might be the first time I skipp a release since 2018, and certainly on purpose. (I usually donât do x.0 releases) Because as I understand it I will now loose the option to extract files from local backups.
Not against encryption or cloud, but taking away options is normally a step in the wrong direction. And its usually best to make sure its really worth it before doing so in an official release. Curious to the thought prosess that led to this decision to force encryption for all backups. Im sure it will be fixed by 2025.2, and we will end up with something really good eventually, but here we are. Happy 2025
@RKor No I did not find a solution.
@lobolobo I use the HA native (Ecowitt) which is currently on version 0.7
Iâve created an issue hoping this can be fixed soon! Untill than I wonât update to 2025.x
Add another voice to the list of âforced encryption in backupâ is a poor choice.
The modularity of the backup system looks good. The encryption should have been a switch INSIDE each modular backup provider.
Nabu Casa backup encrypted on the way out? (Y/N) Yep!
Local on disk backup encrypted? (Y/N) NopeâŚ
Etc. As modules get added.
The design is backward.
Only as an example: Where exactly were the 6 month depreciations infos which broke now card_mod?
I agree with the depreciations approach. If a change and depreciations has a real and good reason. Bat there are many more changes without depreciations and at least my gut feeling is, that there could be a more considerate approach in many changes.
I like the new backup feature and I think backups should always be encrypted.
Right now I use some shell-script to create, move and delete backups, but I would 't mind switching to an official solution.
The reason I opted for UNencrypted backups in the past was only because I cannot access UNencrypted backups in an uncomplicated way.
Fix that, as you mentioned in the Livestream and (almost) everyone will be happy.
No - there is a need for an option to continue to backup unencrypted. Many of us have use cases where encryption does not make any sense, and only adds net negative value.
So I am adding my voice to those asking for unencrypted backup options.
I am also adding my voice to those asking for unencrypted backup options.