TBH, I didn’t know that encryption couldn’t easily be turned off when I updated. I expect a lot of people similarly thought that ti was an option.
3 Likes
Does this tool still work? Didn’t have the time to test it out yet…
It seems to be using a modified securetar version (according to the source code) to circument some issues when being used with Windows OS.
I would also vote for a cross-platform tool as binary without any deps on all major OSes (Win/Linux/Mac) to support easy decryption.
Welli t’s a good practice to always encrypt backups, it removes a lot of security concerns with storage system of backups. If it uses a good encryption system than you can basically store backups everywhere you want even a public place as it can’t be decoded without the key 
The encryption key of course is secured in a good password manager.
It may be a good practice to encrypt if you are a naive user. However, it is the height of arrogance to assume that a sophisticated user doesn’t know they are doing! You have no idea how secure my backup repository is due to other measures. Encrypting encrypted files is pointless and inconvenient as hell. This needs to be made an option that can be disabled by an advanced user.
8 Likes
I just gave it a try. I needed to patch the filename generation and it worked. The 4GiB mariadb addon tarball take 44min to decrypt…
--- scm/foss/decrypt-ha-backup/decrypt-ha-backup/__main__.py 2025-01-04 19:42:53.654166702 +0100
+++ /proc/self/fd/11 2025-01-04 20:13:26.908165966 +0100
@@ -128,7 +128,7 @@
@property
def fileName(self):
ext = ".tar.gz" if self._backup.compressed else ".tar"
- return f"./{self._slug.replace('/', '_')}{ext}"
+ return f"{self._slug.replace('/', '_')}{ext}"
@property
def slug(self):
1 Like
Just rolled back to my prior backup before 2025.1 due to the forced encryption. The files are totally inaccessible in windows.
I’m a Nabu Casa subscriber, and I get why any cloud backups would mandate encryption, but this is terrible for normal backups.
Restoring a backup is a lengthy and annoying process. Diving into the unencrypted tarball to grab a lovelace dashboard or integration config that I realize I want to revert back to is my major use case outside of totally breaking my HA install.
6 Likes
Just to add on, does 3…2…1 even make any sense for home assistant?
I can’t imagine any situation where I’d have lost both my on-device AND NAS backups where I wouldn’t need to start over from scratch with H-A anyhow, because anything catastrophic to both local backups was probably catastrophic to the entire structure.
1 Like
Where did you learn this? Mine appears to be creating backups still, however I haven’t attempted to use them.
This is bonkers - by all means switch on encryption by default but at least let the advanced user switch it off.
Thankfully I also use Samba Backup - Current version: 5.2.0 which is still doing unencrypted backs as per my defined schedule and storing them off to my onsite NAS.
lcsneil
1 Like
Are you sure backups are not encrypted ? Can you extract the xxx.tar.gz ?
What HA version do you use : haos ? ha container ? ha core ?
Following this thread as i am the only one with access to my storage, while not storing any data in HA that i need to be encrypted, therefore i see backup encryption pointless royal pita in my use case
HA development is absolutelly awesome and I am sure everyone is grateful for anyone’s time put in developing HA, no matter how small. I understand HA devs look out for the benefit of all HA users, however, I do think it is not great at all to force users on automated and encrypted backups.
We need options to tailor to our individual needs, and this has now been taken away with the shift to automated and encrypted backups.
For my case, my encryption locally and on the cloud is handled by myseff on a larger scope that just the Home Assistant backup files and it is therefore completely unecessary and PITA to have these backup files encrypted.
Also my requirements for backing up are for when I am carrying out code and dashboard updates. I may go for weeks without any modifications and therefore an automated backup would only waste resources in my case. If I update code and dashboards, then I back up manually, in addition to git version control.
In addition, now there is no option accessing backed up code externally! Sometimes, I may want to see some yaml code for a few months ago, but now it is not possible since the files can only be decrypted after loading back to HA!
I understand these chages are meant for everyone’s benefit, however, can the main dev team please add back the option for non encrypted manual backups without the need to set up an automated schedule.
1 Like
Yes I can extract the individual xxxx.gz files from the .tar.
Cant go any further though and open the .gz files (using 7-zip).
I did manage to restore a backup a couple of days ago after a zigbee2mqtt update without putting in an decryption key.
On raspberry ip4
- Core2025.1.0
- Supervisor2024.12.3
- Operating System14.1
- Frontend20250103.0
lcsneil
This is the problem, datas are in the .gz files we can’t extract it in 2025.1.x versions !
Just switched back to AutoBackup integration, which works great (without encryption).
I’m tiggering it from NodeRed in the following way:
- Creating a folder /share/backup/mariadb and /share/backup/influxdb
- mysqldump of the MariaDB to /share/backup/mariadb
- influx backup to /share/backup/influxdb
- Executing auto_backup.backup_full and excluding addons mariadb and influxdb
- rsync of /backup folder to cloud storage
This works fully automated, without encryption.
BTW: I just found out, that when testing the resulting backup tar-Archive inside the HA terminal for consistency, I always got a
tar: invalid tar magic
error message. This always happens when accessing the share.tar.gz inside the backup. I thought this indicates a corrupt tar-file, but meanwhile I found out, it’s only due to the busybox tar Version, which is used inside HAOS. When copying the tar file to a Debian Linux Box, there is no issue extracting the main tar archive as well as the tar.gz files inside the tar archive.
The backup tar-archive is recognized by HA (Settings->System->Backups) as manual backup, so everything seems to be okay. Will now try to recover it in a newly provisioned HA VM on Proxmox to cross check.
I am in same situation, HA restore fails and I can not access files in the backup file due to encryption. my system out of order and have to rebuild 
Just updated to latest Home Assistant and went through the experience of finding that backups are effectively useless now, albeit with a pretty front end. Running manual backups for the foreseeable future now.
This encryption implementation looks to be very immature. Hopefully the ability to remove keys makes it to the codebase. Soon.
1 Like
That’s exactly it! If I ever need the encryption I will sort it out at-rest on endpoint…
The place I’m encrypting to, if anyone got there, the ha backups would be my least worry (proper sensitive data out there)
I am also in the same situation since the update 2025.01. Backups cannot be really verified and there is no way to restore a backup easily in a docker environment. Providing an own encryption format is a nice idea, but there are enough working and widely supported solutions, so i think it is not really necessarry und usefull. Please allow to make a backup without using a special format and encryption (or just add an option to disable this encryption)! Many thanks!