I haven’t upgraded yet, but I have been following the discussion around backups.
One thing I’m still confused about, is if the local archives produced by the new automatic backup feature are indeed encrypted?
Enforcing encryption for backups that are uploaded to third-party cloud storage is reasonable in my opinion. I don’t think though, that the local archives should be encrypted as well.
My suggestion would be to make a two-step process.
Create unencrypted archive on a schedule and manage those using retention policies.
Only encrypt the archive before it’s uploaded to the third-party cloud storage.
This way advanced users would still be free to handle their data as they see fit. Users who don’t want to worry about this can enable Nabu Casa backups and enjoy a convenient and secure backup solution.
You can still do partial restores of the backup, nothing changed here. If you’re digging into the big backup zip file, looking for an old version of a yaml config and checking if it’s the one you need, you’ll enjoy version control.
Anyway, this conversation will end once they add a simple button to download an unencrypted version of the backup, or something like that. And they will.
But if on the route, they can give a thought (or add to roadmap) to a way to give users this kind of go back to a previous working version of an automation/script/esphome/config/…, these days feedback will have been worth it.
Good point. I’ve always used the term “archival” backups to distinguish them from DR backups. The schedule and retention period are different for each, and it’s typical to save DR backups off-site and archivals locally. Typically archivals are incremental backups, while DRs are full. Some operating systems incorporate version control into their file systems (e.g.; “previous versions”) to give an automatic archive capability.
Just to reiterate, if you are using any custom solution for backups (blueprints, automations, or add-ons that do not use encryption), they will continue to work today. Even with everything new, we’ve made sure to keep everything backward compatible.
As always, we’ll keep improving the functionality of automatic backups over the coming releases. As mentioned in our recent livestream, we’re looking at ways to decrypt your local automatic backups from the UI. This would be helpful if you needed to access the files in them. Hopefully, we’ll have more on that soon.
You are right on your more nuanced definitions.
History is the most accurate description which is part of what VC provide but the latter includes the whole distributed concurrent edits thing we don’t necessarily need here… Unless you are in a multi-tinkerer household
Restoring a single file from the backup is a partial restore, you can’t do that with the new backup implementation in an easy manner looks like some folks were able to hack their way through some options. Partial restores as implemented only allow for a full add-on restore or the full settings restore which is more then what’s needed in most cases.
I also think there is a bit of a misunderstanding in what folks mean when they say version control, saving the last x versions of a file is not version control its version history. Version control would need to include the ability to purposely define versions and merge versions which would be quite above the scope of this project
I hope they will, but all conversation I have seen around this the core dev team has been quite resistant to provide a non-encrypted backup option despite large feedback during the beta and post go live.
Let me just say I love this new feature,
Of course there are possibilities for improvements, there always is. But this is something I was hoping for for a long time.
My previous backups didn’t have a password set, simply because I was to lazy to setup it up and save the password.
Now I’m forces to, which (hopefully) is not that bad for me.
Big thanks to the devs making scheduled and external backups possible out of the box.
In all my decades supporting computer systems, I’ve learned not to rely on hope.
I won’t repeat all the possible pitfalls of this approach, which have been spelled out here and in the other related thread. But I will point out that no-one is asking that the option to encrypt be removed. Just that the option to create unencrypted backups be restored.
Does HA OS support raid yet? In my experience drive failure is a lot more common than lightening strikes! Even a way of running two SSD’s for the OS and being able to restore a backup on the secondary in case of primary failure would be helpful.
I wish there were more elaborate customisation options for scheduling and rotation strategy.
There’s little to no benefit for keeping daily backups from the last 30 days, but it makes a lot of sense to keep ones from (-1D, -2D, -3D, -1Wk, -2Wk, -3Wk, -4Wk, -3Mo, -6Mo).
It spares the storage space while giving you more flexibility if you realise you removed a script 3 months ago and would like to take a look at it.
Synology’s HyperBackup absolutely leads the way in this aspect:
