However,
I do have a backup strategy that has 7 days & 3 weekly (for when you don’t notice something has broken immediately). Held in differing locations (local, local NAS, cloud).
Encryption of Backups: Apologies, but when such significant changes are made, backward compatibility must be ensured over several releases. And features like encryption should be optional and configurable by the user, allowing them to be enabled or disabled.
Why is encryption mandatory? Is the ‘Home Assistant Cloud’ not secure?
Every user should be able to decide for themselves whether and how to encrypt their data…
Requiring encryption keys for backups is incredibly frustrating, and I urge you to backout this change ASAP.
End-users are the best to decide how to keep their data secure.
I am a data-security professional, and the best way I choose to keep my data safe is by making sure my backups are accessible. This means ensuring their reliability, and I choose to keep mine unencrypted to increase reliability.
I am the best person to decide my data-security practices. I am more than capable of keeping my backups safe.
By requiring encrypted keys on backups you are only requiring us to find non-standard backup solutions.
Please make the encryption keys on backups OPTIONAL.
Frankly, all of the backup changes should be rolled back until they are properly thought-out.
I believe that users should have the option for having optional encryption for local backups but, with regard to the above point:
Nabu Casa wants to be able to prove that there was no way they looked at your personal data in the event that your privacy is compromised. They also want to ensure your data is safe if they suffer a data breach. I completely understand why they want your data encrypted before they store it.
Whole restore - About every 2x years.
Single file extract - About every 2x months.
Main use case is unpacking the *.tar.gz to get direct access to a config file to check against the current version - useful for debugging, and general version control.
I also sometimes uses the *.tar.gz to help configure a test pre-production install running on separate hardware (e.g. testing, Beta version, new ideas).
There are other uses - unpacking a backup is the only way to extract Mosquitto MQTT Add-On system_user.json “system” account credentials:
Whole backup restore has only been used for hardware upgrades.
Modern uSD cards are pretty reliable, and NVMe even more so.
I well understand the “plausible deniability” protection of a hosting provider from user content (“no access, no subpoenas”) for cloud backups (and UK Legislation) HOWEVER not being to unencrypt a local backup from my own hardware which was created using a standard FOSS library is a very red flag to me.
One major point of FOSS tools is “many eyes make all bugs shallow” (ESR Linus’ Law), but specifically for crypto, I’m going to quote Bruce “Schneier’s Law”:
Please fix initialisation vector entropy, fix file padding, and fix compatibility with standard crypto tooling. I’d prefer AES-256, but get low-end hardware will taker longer than AES-128.
Please undertake another focused security review as has been done before as this is important.
Hello to all and at first a good and happy new year!
What I am missing at the whole discussion of encrpyting backups is to use
generated keys and certificates by the user.
I am sure some and in my opinion not so less users have their own CA (Certificate Authority) or connected to a CA.
So the usability would increase in this case extremely, if users can take her own certificat/key pair.
As conclusion I recommend to “allow” the usage of own certificates
and - of course - allow users to disable encryption.
With best regards
Helmut
There is. Join the beta team.
Settings → System → Updates → 3-dot menu → Join beta channel
This way you can get pre-release beta versions to test and provide feedback to the devs. I had set up a second Home Assistant server to test beta releases, but since the feedback loop is Discord, I won’t bother. Discord is like a room full of toddlers, each trying to be louder than the others in the same room.
I keep the updates for 90 days, regardless of whether it’s sensible.
A 1TB SSD is connected to the Raspi4, no matter how sensible that is - it was cheap. On the NAS, it doesn’t matter…
Data is stored twice, on local SSD and remotely on NAS.
Fix issues in configuration files.
It depends on what I have changed and whether it works. Often after an update to a new HA release.
Interestingly they say the same thing about the forums
Tried that but no luck
There is. Join the beta team.
Settings → System → Updates → 3-dot menu → Join beta channel
Meh. I gave the exact same feedback related to encrypted backups during the Beta,
I was downvoted and ignored.
Ah 3rd time worked 
Thnx!
Just to reiterate, if you are using any custom solution for backups (blueprints, automations, or add-ons that do not use encryption), they will continue to work today. Even with everything new, we’ve made sure to keep everything backward compatible.
As always, we’ll keep improving the functionality of automatic backups over the coming releases. As mentioned in our recent livestream, we’re looking at ways to decrypt your local automatic backups from the UI. This would be helpful if you needed to access the files in them. Hopefully, we’ll have more on that soon.
you are allowed to pay for more.
Isn’t it the main goal of this whole story?
Not sure where you got that idea. There’s only one price plan. Everyone is capped at 5gb.
At least weekly
Calling action “backup.create” from an automation does not work anymore, calling “hassio.backup_full” is a workaround on HAOS, but for obvious reasons not with a core installation in a python venv.
True and unfortunately. Usage of Discord is forbidden in the company I work for and their (used) CDNs are blocked as well on top.
On my system it is still working.