I also do not like the new backup system, for cloud storage encryption is ok with me, but for my local backups to my NAS I do not want encryption.
The other thing is not automating backups before upgrades or for add ons! This is an automation platform and these backups saved me from alot of problems in the past when an addon update broke something in my system or an update broke some custom integration. I understand that I can use the backup from the night before but I will loose hours of data, and remembering to do a manual backup before upgrading is just stupid in an automation platform!
It cannot be a good idea to remove the “selectable” option to backup before updating, nor can it be sensible to force users to create ways of decrypting backups for storage on our own systems and local cloud solutions. This is just backwards steps for automated backups that can already be achieved using an automation.
I will not update until these issues are addressed, its not worth the risk or the potential hassle. I am very worried about these changes, I can see a whole heap of disappointment with this new system going forward and I don’t want my system failing because of features that have been taken from or forced upon us in updates I rely on.
Seems to be a lot of upset in this thread regarding the new backups…
Personally I think this is a great change and long overdue. No more need for add-ons to manage backups and retention, developers only really need to implement the core storage functionality and the rest is managed by the Home Assistant core itself.
Additional functionality can be added easily, and it would also apply to all backup agents if added as part of the core backup feature (and to be honest, they aren’t overly difficult to build).
Implementing the whole backups automation into core seems a good idea, but as life shows, it likely never satisfy all needs and provide solution to all use-cases. Thus saying it will result in no more custom backing-up integrations is a long stretch. Especially in HA world when all most things are done in multiple iterations, sometimes 2 steps forward followed by 1 back. Long live to custom integrations
for what it’s worth, I’m still using my custom backups while testing the new automated backups. So updating shouldn’t be a problem if you have a custom setup already. Nothing changed in that regard.
Yeah depreciation of the legacy system is a long way off. It hasn’t even been announced yet. Hopefully there will be a lot of improvements before then. SAMBA backup continues to work for me while testing the beta.
If Samba continues to work I will implement that. At the moment my daily backup’s are just a simple “at 12 Noon run the action Home Assistant Supervisor: Create a full backup” and I expect that this will default to the new system after an update with the encryption I don’t want.
There is a trade-off between the convenience of cloud backups, the user protection of encryption, the protection to Nabu Casa of encryption, and the ability to take a backup and expand the individual .tar.gz parts for a whole raft of reasons.
Sadly, the “plausible deniability” protection of a hosting provider from user content (“no access, no subpoenas”) is going to beat the needs of a few technical users.
All I can say is look how quickly a community member read the GitHub code and wrote a backup decryption tool in Python!
THANKS to those patching around this initial feature release.
The best outcome I’m seeing is a modular backup storage system (scp>SMB3> ftp, IMHO), and a reliable decryptor.
Oh hm I tested this with the macOS extraction code in Finder and that one just works. I think it’s caused by this issue with the securetar Python code that’s used by HA to create the encrypted backup:
The CRC bytes are written at the end of the file and this securetar library messes that up with the AES-CBC padding. Bleh
I really wish HA had used a more battle-tested encrypted-archive format.
I trust and like a lot of the folks here on this forum, but I feel like a web tool where I upload my encrypted backup and the encryption key is a bridge too far. I think a local version of this would probably give me fewer heegie geebies.
The devs said they don’t use the available closed source archive encryption method. It is encrypted with an open source method after it is compressed. So it has to be decrypted with a python script before you can decompress it.
Just here to add that I am really hoping that the change to ‘encryption only’ is being at least softened. I have been using the HASS Docker version, so without the option to run any ‘band-aid’ add-ons to still being able to generate and restore unencrypted backups.
As someone who works in the cyber security industry (I’m a CISSP), I agree that the current solution is not acceptable.
Encryption usually increases recovery times (MTR) and often reduces reliability, so should only be used for storage on another person / company’s assets (ie the cloud).
Consider that onsite backups (ie NAS / external USB / etc) might already be encrypted media anyway
Totally agree that anything uploaded to any external (cloud) provider should be encrypted - but the encryption key should be user defined (and the strength is simple to check to prevent Password1234) and must not be stored with the backup.
So, the flow should be:
Backup the files into a local archive file (ie on the HA device / VM) - this allows for fast recovery
If a local destination is provided, then encrypt (if requested), during transfer.
If a remote destination is requested then encrypt during transfer.
I’m on the fence about automatic backups… I manually do backups before upgrades anyway - with a descriptive name - but as long as there’s a way to simply roll back after a failed upgrade, that’s all that matters.
And it would be really good if there was a way for the system to check that the backup was a valid archive by attempting a dummy restore (ie to RAM or /dev/null )
I found myself quoiting Bruce Schneier in the main 2025.1 thread which generally suggests a really bad day for CISSP / CISO / CTO
IMHO, the mandatory crypto is more about NC avoiding lawful intercept subpoenas. This is understandable given current UK, EU, and some US legislation.
#include <crypto.h> and not adhering to standard implementation practices is another issue entirely (e.g. deriving the IV from the key, not raw entropy).
Bruce’s Law basically says “never roll your own crypto - it will be broken, even if you don’t know enough to realise”.
I have used HA now over years in my home environment (virtualised) and approciate the development and progress of HA. Also I am a Nabu Casa Cloud User to support Nabu Casa and any developer here. But I am in the same boat as many of us.
I cannot agree that Nabu Casa, or any developer are forcing us to encrypt data without my agreement. This prevents me to use my well established backup scenario, which is and will ever by in my control. Not NABU CASA or any developer should decide or force any user, how they handle their data.
Cause of the encryption many addons or even my own configuration files cannot be accessed in an desaster scenario now, which cannot be the sense of this “new” feature.
I unerstand that data security and encryption is mandatory, if you offer a billable service (e.g. cloud backup to NABU Casa), as I am living in the EU and know well our DSGVO requirements. But I also believe that to force an encryption of local backups in my own environment with data which is NOT in responsibility of NABU Casa or any developer would be illegal. This, cause I cannot access my data in the new backup files (without hacking around) …
So I hope that you improve urgently the backup feature in 2025.ff, where WE as YOUR CUSTOMERS can deside by ourself, if we want encrypted backups or not!
If you think that there is “no way around” that, you will make it worser for may of us. For my person I will never use your “encrypted” backup procedure in future and find ab alternative way (Samba; Docker Image backup), cause as an IT Professional I know very well that directly encrypted backup (not the backup storage) are a horror scenario if a desaster scenario fails. Nor I understand, why you force us to “FULLY RESTORE” everything at any time anything. This does not make any sense?
BR Rainer (using HA since years now, but at the moment I am really shocked about your decision) …
I am all for encrypted backups… but I do need to be able to easily decrypt a backup with 7-zip whenever I need to extract an old YAML or other config file. I don’t think this is asking for too much, since most extraction tools support strong encryption.
Why have the HA developers chosen an encryption method incompatble with something like 7-zip?
