2025.1: Backing Up into 2025!

[tom_l]

Same advice:

@tom_l

Both of those are 3rd party integrations. If you want them fixed you will have to open an issue with the 3rd party developers (if there isn’t one open already).

Looks like there is already an open issue for the Tuya ( ) integration with a forked repository listed that does work.

The other one seems unmaintained.

[Buzze]

I’ve found in the logs on HA version 2024.12.5 that it dropped a warning “Entity media_player.aimp (<class ‘custom_components.aimp.media_player.AIMP’>) is using deprecated supported features values which will be removed in HA Core 2025.1. Instead it should use…” and “Entity None (<class ‘custom_components.openrgb.light.OpenRGBDevice’>) is using deprecated supported features values which will be removed in HA Core 2025.1. Instead it should use <LightEntityFeature.EFFECT|17: 21> …”. But again these are only warnings and not errors immediately noticeable, I think a HUGE improvement to UPDATES would be to display what is changed and what will be affected in the next version PRIOR to updating, just go over the integrations with the affected things and say that it won’t work with the next version. I think this SHOULD be addressed soon because many integrations are old and can be updated prior to updating a HA instance and not after with a broken integration. This would be a much nicer way to handle updates.

[tom_l]

To be fair to the HA team that warning has existed on your system for 6 months.

[Eikefree]

i tried it to install, and it worked !!! dont know why, but it is working, thanks for your suggestion

[petro]

@Buzze

But again these are only warnings and not errors immediately noticeable, I think a HUGE improvement to UPDATES would be to display what is changed and what will be affected in the next version PRIOR to updating, just go over the integrations with the affected things and say that it won’t work with the next version. I think this SHOULD be addressed soon because many integrations are old and can be updated prior to updating a HA instance and not after with a broken integration. This would be a much nicer way to handle updates.

Guess what? We did that with an MQTT change sometime last year. The repair did not go over well with the entire community. There was a large backlash, so things for developers will remain in the logs and out of the UI.

[Buzze]

But a pop-up warning would be nice anyway before the update takes place, because let’s be honest many people don’t have time to look at the logs.

[petro]

please read my last response.

[PastorAutomatos]

I agree 100%. Most likely, when I really need the backup I will be unable to find the encryption key. To alleviate this, I will try to store the encryption key together with the back thus making it pointless. In addition, this will likely make it harder to automate verification of backups.

I am sure that there are people who are much more structured than me and who have an organized way to store such keys. They are the same people who would never forget their root/admin password because they have it written down. However, people like me need a way to deal with security and the kind to security that works best for me is physical security. I will store the backup on physical media in my house and trust that that will make it secure.

[pergola.fabio]

Question: if the backup is encrypted, let’s say you install HA on another hardware, is it possible then to restore?

[ChipMIK (Michael Kærsgaard)]

I haver never ever before seen an update with so much broken. “KEBA” is part of HA and broken too. My point was the 2025.1 seems to be hasted through or simply include way to many changes. I’m fully aware of what HACS is, but also believe HA should respect how important HACS are for HA to be the success it is.

[KennethLavrsen]

I do not understand this.

If I put this in Home Assistant in the developer tools the backup.create does not exist

If I put it in an automation the good HACS tool from Frenck tell me the same.

If I create the similar automation in the GUI this is the result

alias: Create Backup in the morning
description: ""
triggers:
  - trigger: time
    at: "05:00:00"
conditions: []
actions:
  - action: hassio.backup_full
    metadata: {}
    data:
      compressed: true
      homeassistant_exclude_database: false
mode: single

The documentation Backup - Home Assistant describes backup.create but it seems to not exist. This is very confusing and must be a bug.

[ChipMIK (Michael Kærsgaard)]

Outright stupid a workaround like that is needed in my humble opinion but thanks for sharing

[juergenjw (Jürgen W.)]

It might be different with a HassOS installation? My home assistant installation is running in a docker container.

[tom_l]

@pergola.fabio

Question: if the backup is encrypted, let’s say you install HA on another hardware, is it possible then to restore?

Yes as long as you have the encryption key.

[gerald-00 (Gerald)]

I don’t want a backup in any ‘cloud’, but rather locally on my private server, whose data is regularly backed up. Therefore, I don’t need encryption in Home Assistant with the risk that the key or password might be lost. Servers and backups already store the files encrypted anyway.

I would like an option to choose encryption.

I have often had to search through backup .tar files for configuration files and edit them, just to restore only those specific files independently of a complete backup.

PS: I use ‘Samba Backup’, which works reliably, and I am very satisfied with it…

[snemarch (Sune Marcher)]

First of all: MVP can be a decent strategy when launching new features, but it should not be used when replacing existing functionality, especially not critical system functionality like backups.

It’s good to have encryption of backups as an option, and I understand why you might want to mandate it for Nabu Casa cloud backups. But please do make it optional for local installs.

Proper key management is hard, and a user being unable to restore backups because they misplaced the encryption key is a much larger risk than (local) backups getting stolen. If somebody has access to local backups, they’re almost guaranteed to have access to much more interesting things already, including secrets.yaml and whatnot.

I haven’t had to peek around my backups very often, but when I’ve had the need, it’s been nice that I could just go in and find a few snippets of configuration or whatever. If I had to restore a backup, I would have lost later changes to get those few snippets back - or would have had to do an even more time-consuming process of making a new backup, restoring old backup, copying snippets, restoring the newly-created backup, applying the few old snippets.

I also don’t want the additional overhead of encryption, however small – I don’t gain any security in my local backup setting. Sure, AES is fast on modern hardware, but Raspberry Pis are still pretty weak devices.

Also, it would be nice to have the time-of-day for automated backups be flexible (something that’s fine to release in MVP fashion). We’re probably a few people who backup to a NAS location, without time schedules for spinning down harddrives, or even a schedule for starting the NAS at all.

[Zweierpotenz]

@cogneato

You can make unencrypted full or partial backups through yaml automations, scheduling them when you want, and sending them to the location of choice, same as always.

Your screenshot mentions Supervisor; do installations without it still have no other option beside the local encryption? On my Docker installation only backup.create is available.

[snemarch (Sune Marcher)]

Is supervisor/supervisor/backups/backup.py the file responsible for backups? Please tell me that I’m hallucinating, and you’re not deriving the IV from the encryption key

If you want to do encrypted backups, please:

1. Don’t roll your own, use a well-designed, standard format.
2. Get somebody on the team who has the required expertise.

Badly implemented crypto is worse than no crypto.

[petro]

They didn’t roll their own, they are using this lib for encryption

https://pypi.org/project/securetar/

EDIT: I guess this is a bit subjective. It’s an open source encryption lib for tar files, where the main dev’s have all contributed.

[Mariusthvdb (Marius)]

this is new, and peculiar

cloud is available, so why couldn’t it upload?
maybe they are overloaded…

or is cloud.cloud an issue

also, the card is not wrapping

checking the logs as is suggested reveals this in SU logs

2025-01-05 14:30:40.725 ERROR (MainThread) [supervisor.backups.backup] Can't read backup tarfile /data/backup/0a57e388.tar: "filename './backup.json' not found"

but that isnt the cloud, because mid day, and not at th scheduled cloud time

host logs are all ok, and dont mention backup at all