2025.2 Beta Backup changes

[danieldeni]

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.

[bkbartk]

@maxym

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

There is an international dateformat.
It contains leading zeros.

[CaptTom (Tom)]

If there were to be a redesign here, my vote would be:

• YYYY MM DD format, delimited however you choose. For ease of sorting.
• Leading zeroes, again to support sorting.
• Date first, or just after any static prefix. Sorting again.
• Include “Full” or whatever part the “Partial” is.
• No need for milliseconds.
• No need for extra _ . _
• “Automatic_backup” seems a bit long, maybe “HA_Auto” or “HA_Manual”.

These are just suggestions. I’m still thrilled we got away from slugs for file names.

[Baxxy13]

@Baxxy13

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

In 2025.2.0b6, the backup size is still almost doubled.

Edit:
Could fix this.
During 2025.2.0b4 i had 2 local storage locations and somehow 1 backup lands in a wrong directory which then becomes part of followed backup later.

# ls -al /mnt/data/supervisor/homeassistant/backups/
total 102948
drwxr-xr-x    2 root     root          4096 Feb  1 11:05 .
drwxr-xr-x   14 root     root          4096 Feb  2 13:13 ..
-rw-r--r--    1 root     root     105410560 Feb  1 11:06 Automatic_backup_2025.2.0b4_-_2025-02-01_12.05_32912886.tar

After deletion of this folder with it’s content my backup size was back to normal.

[maxym]

@bkbartk

There is an international dateformat.
It contains leading zeros.

not sure you noticed, there were exclusively European countries included in the discussion. Every such country has its own convention. Even on the official level (ie EU documents), there is no single standard enforced.

Speaking about the international format, you mean likely ISO 8601. But at first it’s YYYY-MM-DD format (so not widely used in Europe), at second, while it’s currently being implemented in Europe, it’s rather advice rather than real change. I’m not aware of date-time format changes in the countries I live.

[Protoncek (Pavel)]

@maxym

not sure you noticed, there were exclusively European countries included in the discussion

…which is logical, as only european people are affected with “wrong” date format

Leading zero or not, most (if not all) EU countries use time, followed by day-month-year, while US uses reversed format…

But, since most important thing to look for is international compatibility and possible problems when not using it i guess current format is best to use.

EDIT: but then again, many other things are also reversed, say numbering: number 25: many EU countries say five and twenty, while US says twenty five.

[maxym]

shhh, otherwise HA team will bring this number pronunciation idea to HA

[bkbartk]

I didn’t know only European counties where involved.
But it fixes the dateformat issue globally. And you can sort on alfabet and still get the correct order. Whenever doubting this format fixes a lot of isseus. Still. M$ for instance tries to ignore this format as much as possible.

[Deedee]

Ah, ok…if it’s not backing up all folders then it is a partial backup and the logs make sense. Thanks!

[arythm]

I am not participating in the beta but it was important to me to also add my heartfelt thank you for you dealt with the community response.
I have read the beta release note a day ago and was impressed with how everything I had read in the blog thread was addressed. Thank you!

[bkbartk]

I think I also miss the addon_configs folder.

[danieldeni]

addon_configs is not part of a Full Backup, never has been.

[bkbartk]

Is there a reason for this?
I have 1 addon storing the data here. Or should I ask the addon dev to store the data somewhere else?

[mucki]

@bkbartk

I have 1 addon storing the data here. Or should I ask the addon dev to store the data somewhere else?

Same here with two addons. I haven’t installed the beta yet, so I tested it with Samba Backup because it doesn’t encrypt it. The data from addon_config is saved directly in the backup of the addon (config subfolder).

[danieldeni]

This has nothing to do with the new backup method introduced in 2025.1.0 .

All add-ons that exist like Samba Backup, Google Drive Backup and OneDrive Backup use the old scripts (that still exist) to make an unencrypted backup.

action: hassio.backup_full

I still run it daily to be sure I have a working backup during the betas, in case something is wrong. And they are still unencrypted if you don’t set a password, like with the add-ons.

The addon_configs was never included as a folder. If the add-ons are made properly the data should be included in the back-up of the add-on itself which is part of a Full backup or Partial backup where the Add-on is included.

You can check an unencrypted backup by opening the .tar and the .tar.gz inside of the specific add-on.

I just checked through the new method and opened a0d7b954_nginxproxymanager.tar.gz. The data from addon_configs is inside the config folder of this file.

[bkbartk]

@mucki

The data from addon_config is saved directly in the backup of the addon (config subfolder).

I checked this for my addon and this is true, meaning the files are backed up so there is no need to change this behavior.

[nrasmussen (Niels Rasmussen)]

@maxym

Speaking about the international format, you mean likely ISO 8601. But at first it’s YYYY-MM-DD format (so not widely used in Europe), at second, while it’s currently being implemented in Europe, it’s rather advice rather than real change. I’m not aware of date-time format changes in the countries I live.

ISO 8601 has been around for almost 40 years. I don’t understand why it hasn’t been more widely adopted. However, whatever the reason, there should be no question about using it for the purpose of this discussion.

[MissyQ (Missy Quarry)]

Just a quick post-weekend update:

The team is aware of the date feedback from this thread.

[Protoncek (Pavel)]

I thnk it was already stated: unneeded warning appears when downloading unencrypted backup file, something like

decrypting is not supported for this backup copy. Downloaded backup will stay encrypted and won’t be possible to open it. You need a decryption key for restoring

(translated from local language).

Warning still shows on beta7. File can be easily opened, though (since it’s not encrypted).

[piitaya (Paul)]

It is fixed on beta 8