3…2…1… Backup

Well, it’s not as user-friendly as just a click on a button in the UI that worked perfectly fine before. If you’re using docker container you can also backup the whole container folder I guess. But why do that if there is a Backup setting for it in UI :person_shrugging:


There could be 2 options in the Backup Settings UI:

:white_check_mark: Encrypt automatic backups
:white_check_mark: Encrypt manual backups

that’s all, problem solved! :slightly_smiling_face:

OK, I am fine with just one option:

:white_check_mark: Encrypt manual backups

3 Likes

Why is the title 3 2 1 backup? It doesn’t work like that at all.

Also, 3-2-1 is already outdated. You should look at 3-2-2 or 3-2-1-1-0.

Previously with the Samba backup I had X amount of backups locally, and Y amount of backups on my Unraid server, and with a script I moved those server backups to another location.

I added my Unraid server as backup location, and I selected 4 backups. But now I’ve got 4 backups locally and on my server. That’s useless and doesn’t come near the 3-2-1 method. Why do you use such a title when it’s not implemented at all?

Hopefully it will improve soon.

Thanks for explanation. I’m glad that third-party addons will still work.
However, encryping LOCAL bakups is needless - it makes no sense to have encrypted file locally, together with all other UNencrypted HA system files, don’t you think?

Backup program should make UNencrypted file locally, then encrypt it and send to cloud - mandatory encryption is totally ok however when/if sending files outside HA, i kinda agree with that part.

The need for a decryptor is just another (needless) time consuming step in between for us, users, and additional work for you. One simple switch (optional non-encrypted file) would solve all…

But even if you’ll stick with your mandatory encryption, the only fair solution for us, users would be to disable it until you have decryptor…

13 Likes

It is OK except for the naming rule of the backup files. All got the same name. I would prefer a standardized name like YYYYMMDD_HHMMSS that is useful and logic and will make no confusion. And it will sort nice on any list/table on any system.

1 Like

Auto backup for updates needs to be added back. This feature is key for rollbacks to previous versions. It should not be that users should have to remember to do it manually. Maybe the Home Assistant team that developed the new scheme can add a third “Upgrade” backup type to the menu as in; Automatic, Manual and
Upgrades.

I would also like others to have the option to backup an unencrypted version or decrypt an encrypted backup so that I can extract information from a specific file.

12 Likes

no, IMHO for preventing snatch your some passwords in config files.

Look at the Google drive backup addon. You don’t need to use Google backup for it , you can still leverage all your help features for local only backup

1 Like

Is it necessary to say goodbye to the convenience?

1 Like

+2 on "Everyone is waiting for you to say: “We’ll give an option to leave the backups unencrypted in the next release”.

Thank you very much but we’re all a big boys and girls here. We can decide for ourselves what if any encryption we need based on our particular use case. Being forced to use a key, which can easily be lost, is way more than many of us need or want.

4 Likes

It works like that, yes. One on the HA device, one on a network share, and one in the cloud. That’s 3 copies, 2 in different media locations, and 1 offsite. 3-2-1

3-2-1-1-0 is something Veeam probably came up with which adds one copy which is offline and validated to have 0 errors. How would this copy be made automatically to an air-gapped system through HA? That involves physical interaction or something far more elaborate to take something online and offline every time a backup is made.

Copy it off your unraid server to a usb drive and that put it in a fireproof lock box every day? This sounds like it would fit the description.

Big boys and girls would simply go to the automations page and create a full backup on a schedule or whatever trigger they want (Full moon?) without enabling the password/encryption option though. Then they have what they want.

Big boys and girls would simply go to the automations page and create a full backup on a schedule or whatever trigger they want (Full moon?) without enabling the password/encryption option though.

Now this is something that you (and/or the entire HA team) should definitely insist on. You are getting a lot of hate^H^H^H pushback on this change, and I am beginning to understand that it is not really warranted.

As I understand it, all the backup methods we had before (Google Drive backup, Samba backup addon, manual/automatic backup via hassio.* service, manual backup via the GUI) do not change. All of them work just like before, and they can be encrypted or not encrypted, depending on user preferences. It is just the automatic backups that are encrypted by default, with no option for unencrypted backups.
[ Edited because I definitely misread/misunderstood the post saying “manual backups have not changed”… manual backups via the GUI seem to be encrypted by default as well ]

If this is correct, you should really put this info everywhere (documentation, release notes, blog post, etc). Hopefully it would mitigate some of the… negative reactions to the update :slight_smile:

On another note, please know that (despite all the negative reactions) there are people who really appreciate the change and understand the reasoning behind it. I have been pushing for encrypted automatic backups in HA for a while now (I have linked a thread above), and I believe that “secure by default” is never a bad idea. But you should still consider some of the suggestions above, like allowing the option of unencrypted backups (maybe with a warning?), and providing an offline/standalone decryption utility.

1 Like

That’s true and accepted from my side also. However, in our case it’s not “secure by default”, but “mandatory secure”. Now THAT is what’s the point of this whole argument.
There was “backup by default” when we were updating addons, with option to turn that off - that is “by default” meaning: on by default with option to change that. Now addon updates are “mandatory off”…

8 Likes

That’s true and accepted from my side also. However, in our case it’s not “secure by default”, but “mandatory secure”. Now THAT is what’s the point of this whole argument.

:slight_smile: I almost put this at the end of my comment, then decided against it, because it was already too long of a comment. I will add it again, just to avoid any confusions :slight_smile: But please note that I already agreed to it previously in this thread.

That being said, the point was that anyone who wants unencrypted backups can still get them, using any one of a myriad of existing methods (most of which have not changed in any way). If my understanding of this thread is correct, of course.

Exactly, there are still alternative backup options. At least at the moment. But you can also read the release notes about this from a negative perspective :slight_smile:

No worries, if you are using any custom solution for backups, they will continue to work today. Even with everything new, we’ve made sure to keep everything backward compatible.

2 Likes

Correct, i’m a bit worried about this word “today”, too. I hope that this doesn’t mean that once all of the sudden a small hidden message will appear in HA logs “warning: this function will not work anymore in 2025.x”…

4 Likes

Prior to 2025.1.x whenever we had add-on needing a backup (e.g. those setup in addons, so included custom ones like z2m, and clearly excluding any HACS updates), we would get a prompt on the update page to backup that addon prior to updating.

Now (with 2025.1.1) there is no prompt, no option to backup the addon on the update page, and it does not automatically do it in the background.

How do I re-enable this, or is this a planned change, to make us go to this new backup page, every time we have an update?

This was so useful to have defaulted on, for those times we needed to roll back an update that was not working on our systems.

2 Likes

100% gone and 100% developer decision.

3 Likes

If that is the case, I don’t get the logic behind it, and would love to hear the reasoning behind the change.

1 Like
1 Like