Mandatory encryption does not allow use of backups to make minor version changes using copy and paste of YAML file contents without laborious manual decryption.
No events generated to allow for notification of backup start, success or failure by user’s chosen notification method.
Add-on and core updates no longer have the option to backup before updating which could lead to up to 24 hours data loss depending on the time of update vs the time the last automatic daily backup was made.
All issues raised during beta testing. All ignored / dismissed.
We’ve obviously all been very naughty to receive this lump of coal in our Christmas stockings this year.
Fortunately SAMBA Backup continues to function (for now). And is far more versatile allowing for notifications and separate numbers of local and remote unencrypted backups with cleanup.
EDIT: Reading back through my post above it does seem a bit harsh.
The team have chosen to release what they call an MVP (minimally viable product).
This does not preclude enhancements, which given enough community feedback will hopefully be forthcoming in future releases.
Unfortuantely had to restore back to 2024… Too many things broken - the classic Google Nest Protect no longer works/loads, some of my automations for light color changes getting errors and no longer working. Plus not thrilled about forced encryption for local backups. There is no need for that and should be an option.
I totally agree! Why are encrypted backups mandatory? I have no problem (actually it’s really good) when they make encryption easier by using keys and even to have them encrypted by default, but I see no reason why I should create encrypted backups when I’m storing them on a fully encrypted NAS drive.
I just signed up here to add my name to the list of people being quite unhappy with this update.
I’m running the backup remotely via shell commands and then place them in an encrypted and deduplicated storage solution. Reading the post it should keep working for now, but also sounds like it will be deprecated soon. Encryption for your cloud, fine, optional, fine, but enforced encryption is not acceptable. I don’t want another key AND this is also breaking my deduplication.
An additional question: My biggest issue with the old backup system was that each backup was created on the local file system. Even when connecting via ssh my only option was to create a new backup (ha backups new), copy it via network, clean up (by deleting old tars) and unpack the tar again as there is no option to access the whole file system via ssh. Is this solved with this rework? Creating a daily automated backup wastes the lifetime of my HA Greens eMMC, I just want all the data accessible for my own backup tools (which backup a dozen of other systems as well).
“Soon” is probably not an appropriate adjective. There will be at least 6 months warning whenever the depreciation is announced. And it has not been announced.
I think this needs to be emphasized here. Unless something has changed, backups are created on the LOCAL drive (even if that’s an SD card) then zipped into the .tar file on the LOCAL drive. Only then can they be COPIED somewhere else, like a NAS or cloud storage.
Encouraging frequent backups without explaining this could lead to problems in some installations.
Oh, and I agree that forcing encryption was not a good decision. I’m seeing more of this direction of removing options from HA. It seems like an us-vs-them attitude is developing between HA devs and users. I’ve seen this before. It doesn’t end well.
Heads up - if you have a custom directory under .storage entitled “backup” as I did (for some custom backups when I needed to manually update the entities) the new backup integration will fail to load and you’ll have no backup functionality.
Just thought I’d mention in case anyone else runs into this.
Custom integration Xiaomi Mi Air Purifier, Air Humidifier, Air Fresh and Pedestal Fan Integration
anyone running this custom integration from Hacs, this will break your climate.xxxxx entities as they come up as unknown using this custom integration if ugrading to 2025.1.x
I have created an issue on github
hopefully @syssi still maintains this repository and can resolve
I am using the Google Drive backup add-on to send backups to my NAS and to Google Drive. It offers the option to add a password for encryption. It’s not clear to me whether this only encrypts the upload to Google Drive or both.
Yes - have also been using my NAS instead of the local storage - as well as the Google drive add-on. It’s just as well because I had a failure with my Proxmox-on-thin-client set-up which would have taken out local backups. Set up a new Proxmox/HA on a spare thin client… downloaded the backup from the NAS and only lost about 45 minutes of operation for HA.
Is this the case even if you have selected NAS as the backup location?
At least for Xiaomi Mijia MJXFJ-300-G1 still works.
But I see this error in Log and I think it is related to this integration (seems it should be closed since not reproduced in a safe mode).
A custom integration, so…
Created this issue in that repo.
And it is already fixed))).
Absolutely agree. Why can’t we have the choice of encryption? I mean, it’s fine if you want to default it to encrypted, or enforce it when using nabu cloud or something for liability reasons, but other than that, let users make their own choices.
Unless something very drastically changed in this version, yes.
I do infrequent HA backups, mostly before I’m going to change something. Otherwise, I just copy the /config directory to my NAS as part of my routine backups of other stuff I run.
Mandatory local encrypted backup system? It seems more important than the most voted WTH RBAC that have the total of 0 mentions, at least, in this update.
Also want to add that ‘default’ encryption of backups is good but the option needs to be there for unencrypted local backups.
I’ve got a local solution (Syncthing to my NAS) that also encrypts it and remotely backs it up with the rest of my NAS, encrypted, and this change doesn’t improve my situation but makes it worse as I now have one more encryption key to lose.
It also makes it harder to edit the .yaml in the backup for a correction before a restore.
Automatic backups are a work in progress, and it will continue to be improved according to feedback and usage over the releases. Please be patient.
As for any software products, the best practice is to release early and get feedback first, rather than developing behind close doors for months without user feedback in the dark. This is what “MVP” is about. It’s not just a jargon. Releasing it now also allows contributors to build integrations to integrate HA with more backup locations.
And I mean, you’ve been around long enough and you should know that the contributor team does listen to feedback and continue to improve the product over the months and years. It’s never an “us vs them” situation, and it’s not a black box either - encrypted backups have been on the roadmap since April. And 2025.1 is not going to be the only update on backups in upcoming months.
Also, the beta was done over the holidays. Contributors have families and friends, too. Even though these features aren’t implemented for this release, they are being prioritized, and if features can’t make into this release, there will always be another one to fix what’s missing. These are not mandatory upgrades. Please understand and be considerate that contributors are people, too.
With that said, here’s something that all of you can help!
To make this a productive conversation, it will help guide the development of the backup feature, if those of you who prefers unencrypted backups can help describe your use cases and reasons behind the need. For example:
how often do you open your backup archives?
What do you open it up for?
How often do you need to restore your backups?
The more details the better! This will help guide the UX and help the team prioritize and develop the features correctly! Thank you.
