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
[Edit2:]
@tom_l has merged the requests
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. 
exactly that is what I meant, great. thx
and yes, please also add that common task link, how could it not be just yet 
The docs will likely end up including the content requested. They are still works in progress, though.
Thanks for the clarification.
2 new poblems after update from 2025.2.0b2 to 2025.2.0b4.
I got now 2 local backup locations, before the update it was only 1.
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)
b5 rolled out this morning fixing a lot of what you mention.
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
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!
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
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.
Perhaps the name should also include whether it’s a full or partial backup.
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.
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
Well, this shape:
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…
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.
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.
I am in Europe and I always use the YYYY-MM-DD notation, this helps sorting files/folders logically.
So the default date notation now used is fine for me. The microseconds is not needed, as it will never trigger two backups in the same second. But you might need to have the normal second in it, otherwise the backup will probably overwrite the other backup with the exact same name if they are both triggered in the same minute.
So my preference would be:
Automatic_backup_2025.2.0b5_2025-02-01_17.15.01.tar
or
Automatic_backup_2025.2.0b5_2025-02-01_17.15_slug.tar
Where slug is the backup slug that was the name before the changes. So you will always have unique part in the filename if they are triggered the same minute.
There is an international dateformat.
It contains leading zeros.
If there were to be a redesign here, my vote would be:
These are just suggestions. I’m still thrilled we got away from slugs for file names.