2025.2 Beta Backup changes

[Neil_Brownlee]

Being to able to specify the retention by location would be great - so I can keep more copies on my local NAS and only the last few externally.

[pove]

That’s what I asked above.

Automatic backups only allows one general configuration.

[Mariusthvdb (Marius)]

if you’ll have special feature requests, you should really write them up, so it can be tracked.

only mentioning here wont really help, because the team doesnt follow the community posts.
I suppose even now Missy is listening in here, writing up FR’s is still the best thing to do

[bkbartk]

@Mariusthvdb

but do join the beta and give it a test run yourself

I would if I had the time, at the moment there are 4 projects I would love to do testing for but that also means being able to debug the issue when something fails and that I do not have time for at the moment.

But I will write up a feature request

[Edit:] here is the feature request

Retention per external location for backup

right now, there is one global retention setting. But I would like to set retentnion per destination. so local for 100 days NC cloud, only 1 is allowed, so 1 Onedrive for 30 days. Google drive 7 copies because of size limitations. and probably people using a Nas would prefer to specifiy the amount of copies there as well. Would this be possible?

[Edit2:]
@tom_l has merged the requests

[MissyQ (Missy Quarry)]

Yep, let me take it back to the team. The Common tasks page has a lot more detail on how to configure everything, but maybe we can have some related links on the integration page to the supported integrations.

This thread is also now pinned in the Installation category until 5 Feb.

[Mariusthvdb (Marius)]

@MissyQ

maybe we can have some related links on the integration page to the supported integrations.

exactly that is what I meant, great. thx
and yes, please also add that common task link, how could it not be just yet

[MissyQ (Missy Quarry)]

The docs will likely end up including the content requested. They are still works in progress, though.

[Baxxy13]

Thanks for the clarification.

2 new poblems after update from 2025.2.0b2 to 2025.2.0b4.

1. I got now 2 local backup locations, before the update it was only 1.
   

2. Can’t create a automatic backup with this settings anymore
   

Error:

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/connection.py:315
integration: Home Assistant WebSocket API ([documentation](https://rc.home-assistant.io/integrations/websocket_api), [issues](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+websocket_api%22))
First occurred: 12:20:16 PM (2 occurrences)
Last logged: 3:32:40 PM

* [546667118656] Error handling message: Addons and folders are not supported by core backup (home_assistant_error)

[RickFurtado (Happy Cadaver)]

b5 rolled out this morning fixing a lot of what you mention.

[Baxxy13]

Thanks.

I have now (it is afternoon in europe) updated to 2025.2.0b5 and both problems are fixed.

But now the backups are twice as big because the backup is inside the backup again.

And a warning “Decryption unsupported” when downloading a non-encrypted backup.

The file naming looks good now.
Automatic_backup_2025.2.0b5_-_2025-02-01_17.15_05645651.tar

[CaptTom (Tom)]

@Baxxy13

The file naming looks good now.
Automatic_backup_2025.2.0b5_-_2025-02-01_17.15_05645651.tar

I love it! Putting the version number and date/time inside the name is exactly what I was hoping for. Looks like the Devs really thought this one through!

[Baxxy13]

Yes, much better than before.
The year could perhaps be shortened and the microseconds omitted.

Another example of an add-on backup:
RaspberryMatic_CCU_(snapshot)_3.79.6.20250128-43e8a02_-_2025-02-01_17.28_40788636.tar

[Deedee]

Core 2025.2.0b5. Automatic backups with all backup data & all add-ons selected (Backup settings → Backup Data), show up as partial backups in the Supervisor log. Log sample:

2025-02-01 23:17:09.428 INFO (MainThread) [supervisor.backups.manager] Creating new partial backup with slug ad2df48d

Same thing with restores from automatic backups:

2025-02-01 13:11:31.267 INFO (MainThread) [supervisor.backups.manager] Partial-Restore 8c666189 done

This happens with scheduled automatic backups and with the Backup Now button.

When I use script with hassio.backup_full, the log shows a full backup:
2025-02-01 23:12:19.772 INFO (MainThread) [supervisor.backups.manager] Creating new full backup with slug 7136135d

I’ve done several automatic backups/restores and they appear to be full backups. Is it just incorrect wording in the logs? Just checking to make sure that automatic is actually doing full backups, even though the log says otherwise.

[parautenbach (Pieter Rautenbach)]

Perhaps the name should also include whether it’s a full or partial backup.

[danieldeni]

There is one folder not included in the new Backup mechanism:

Local add-ons folder, which are stored in /addons .Not sure why it’s not included, most users won’t have anything in there, so it won’t make the backup bigger to be able to include it.

The old

action: hassio.backup_full

Still makes a full backup including that folder.

[maxym]

@Baxxy13

The file naming looks good now.
Automatic_backup_2025.2.0b5_-_2025-02-01_17.15_05645651.tar

imo it’s overcrowded. Especially this _-_ sequence is not needed. Could be single underscore.
Also the date time part is not consistent. Why date parts are separated with hyphen, and time with dot? And then seconds from minutes with underscore?
I would simplify the time part, it could be like this:
Automatic_backup_2025.2.0b5_20250201171505645651.tar

BTW using component version in the name is ok as long as length of its sections is guaranteed and format maintained. Once it changes it makes impossible to sort properly.
For example beta15 will appear before beta5.

For this reason, it could be moved to the end of name, letting timestamp secure ordering

[Protoncek (Pavel)]

Well, this shape:

@maxym

2025.2.0b5_20250201171505645651

Is in fact harder to read than

2025.2.0b5_-_2025-02-01_17.15_05645651

I think only end “microseconds” numbers should be omitted (as already suggested), something like:

2025.2.0b5_2025-02-01_17.15

Or similar. But, at the end, if i can be a bit picky: format is wrong for EU citizens anyway… it should be:

2.0b5.2025_01.02.2025_17.15

So it should be formatted according to local time/date format. But, as said, that’s …a bit too picky…

[maxym]

@Protoncek

format is wrong for EU citizens anyway

It becomes even more complex if you consider that some countries (if not most, in EU) don’t use leading zero in month and day numbers. It effectively makes it impossible to sort files by its name, maintaining their order.
Not speaking about other differences in date formatting.

This is why such a timestamp shouldn’t be considered to be user-data (at least not as the most important need). The file name is for organizing files. not for providing localized information.
Every attempt to do the latter falls apart for multiple reasons.

Personally, I don’t have a problem with ‘decoding’ such a string by glance. But yeah, I work daily with such formats so probably I used to them. Saying that such an approach is used everywhere in devops. HA team is again trying to do things differently. Probably thinking that this is end-user-facing functionality

What I agree with you is, that the micro secs part seems to be not needed and adds to the noise.

[Protoncek (Pavel)]

Yeah, it was meant more as a joke than serious comment… (that’s why i wrote “picky”). I don’t mind using “international” format either, neither i expected my “suggestion” to be taken seriously.. I know that this would take way too much (needless) additional coding.