I think nickrout meant that the whole config directory is in the backup. So that should still have your customizations somewhere. You should be able to find them by manually extracting the backup tar file.
But yeah, the backup checkbox kind of gives a false sense of security. As you think all is OK because you made backups, but when you need it it turns out to be not what you need. The dialog does say “Home Assistant Core”, but that is easy to miss and then you still need to remember/realize how HA is structured with HA OS/Core.
A bit more guidance from HA would be nice as backups seem easy to do in the UI but has some gotchas. Maybe a built in/default periodic full backup automation or a notification/repair when fullbackup was a long time ago or you cleaned up all full backups to save diskspace…
Thanks to @Michel 's comment above i found and opened my last 2023.3.3 backup tar and indeed my configs are in there so figured i’d try to restore it, and …
This is not my IP. From the looks of it it fails trying to fetch a docker image but in short, even that backup is borked and crashes my system.
This time around i knew how to recover from that so i restored my febuary 1st full backup again and this time around i systematically restored every partial core backups i had and stopped short of the broken x.3.3 and lo and behold, i have all my customizations although go2rtc refuses to start (outputs no logs Edit: Host reboot fixed it) and astroweather doesn’t recognize the location entity but still this is miles better than earlier.
I now have a better understanding of how the HA backups work. I 'll definitely trigger a manual full backup next time
Anyone else notice odd entities created automatically as part of the upgrades to the ONVIF Integration?
Some of my dome cameras have a white LED that can be turned on for extra illumination at night but these have not been added with the upgrade, instead I got wiper controls… but the cameras don’t have wipers. None of the automatically added switches turn the white LED on.
That’s why I’m doing scheduled backups on a daily basis (full or partial fitting to the needs).
To go one step further you can copy them to a samba share, there is a good addon for that.
No more worries when hitting the update button
Both of those are fantastic add-ons. I’ve used both and they’re well written, well documented and well supported. Kudos to the developers.
Still, they only copy the backup to external storage. The only place HA can create a backup is on the drive it’s running from. That isn’t a good place for it. When you need to restore, chances are that drive will not be easily accessible. I’d much rather see HA offer the option to create the backup on external storage to begin with, where it would be available during the restore. This is especially true if you’re using an SD card to run HA. Frequent backups only invite disaster.
My solution is to only back up the config share to my NAS via SAMBA, as part of my routine backups. That contains all the configuration and the database. I only bother running a full HA backup prior to updating, and even that is probably unnecessary.
That makes no sense. Copying to or creating on the external drive it still ends up in the same place. And access is easy, you can restore the backup file directly from your web browser if you have an install with a supervisor.
I don’t really understand the discussion here, because it is just always the same topic: How you setup your system.
HA is designed to run on a very simple setup - such as an RPI.
Therefore, it provides a very basic backup option - designed for that particular purpose:
Run HA on an RPI, create a backup - store it locally, and in case - you can easily setup a new installation and restore the previous backup…
If you REALLY want to use more advanced options - you should consider to plan your installation in such a way.
For example, use a Proxmox server, Run a VM with HA OS - create your backups through Proxmox on an external storage…
The same applies for the recorder and so on…
To allow HA creating backups on an external storage, you need to:
mount this device within HA
access that drive when HA will fail
but if you have a failed HA, you need other options on access the storage and recover the backup.
in my opinion, backups that are created by the application that should be restored are always limited in some places and options.
Therefore, I would recommend to use external backup options (as mentioned, let proxmox backup the whole VM)…
Very true, however in case of HA you can always make a fresh install and the restore from backup all configuration files over it. Tested few times in the past, works perfectly. Not real restore, rather rsort of ebuild of the machine.
Personally I run HA as VM on ESXi server and use Active Backup on Synology to backup entire VM. This way I can restore it fully from any past backup in less than 15 minutes.
A question about “Restart Home Assistant → Quick reload” feature.
I have some amount of yaml-set integrations (which are part of HA, not 3rd party) - seems that they are not affected by this feature?
Thanks!
Do you know is it mandatory for integrations to have an ability of reloading?
I am going to create issues for integrations which seem to not reload.
I would argue that the default backup option is not optimized for a RPi running off an SD card.
First, there are space constraints on the SD card. Second, there is the issue of excessive writes shortening the life of an SD card.
But even disregarding those issues, the typical case when a restore is needed is where either (1) the SD card is corrupted and therefore the backup on it is unavailable, or (2) you want to do a full re-load of the OS image and therefore will overwrite the SD card, making the backup unavailable.
In either case, the backup needs to be external to the device you’re restoring before you start. It seems to me for all these reasons, it would make sense to create the backup where it would be most useful and not detrimental to the running system in the first place.
I agree with this in particular…
I have another application (my wallbox / EV charger) that is using an RPI as Host for the OS … but even there, backups are created locally on the SD it is running on.
That’s a “common” design approach, because else, you have to mount external drives etc…
All those application are comming with the “download your backup” option…
And all those have the same issues… downloading your backups could cause file corruption, restoring needs additional effort and sometimes knowledge about networks, how to mount devices on linux…
Therefore, they are limited, and designed to be “as simple as possible”… which isn’t something I would use when it comes to “reliability”… and therefore, using HA on an RPI was NEVER something I thought about.
It’s just not the device I would consider for a “reliable” piece of my homeAutomation and Network architecture…
It is OK for remote applications, such as my Wallbox, where I cannot run a complete server… but in fact: I COULD run the main Software on my Proxmox… and just use the existing RPI as a remotely controlled device… this is something, I need to consider in the future.
Anyway:
My recommendation when it comes to backups:
Use other methods to backup your system… the internal backups are “nice” to restore if an update broke an integration…
The error in question here (above) seems to be different… it was not caused by an integration that just stopped working…
100% agreement on this. Perhaps we (the HA community) should do a better job of communicating this to new users. I’ve been reluctant to go against the conventional wisdom of recommending frequent backups using the built-in HA functionality. But it seems we may be setting users up for future problems if we discourage them from developing a backup and restore strategy which works for their environment.
create partitial backups when an update will be rolled out - to have the option rolling back if something should stop working (in fact, it’s also a topic when you notice that an integration stopped working properly)…
Create regular backups of the VM my homeAssistant is running on - in Proxmox, and store them on an external drive.
Optional (but recommended backup strategy) - create a copy of the backup on another location outside your home…
→ also, I moved the recorder to MariaDB, running in another container in my proxmox - so it is completely seperated from HomeAssistant (not running as addon, etc.)
With the Backups created in Proxmox, also backups of the Database will be created regularely.
Especially when running HA on a RPI with SD Card, I would recommend to check what exactly you can outsource to reduce the load on the SD card.
The RPI should be fine as a hosting system for the Software itself…
As far as I got, it should nowadays be possible to attach SSDs and other storage to the RPI - so MAYBE, it would work to have HomeAssistant running on the SD Card and using an additional storage for backups and the Database?
I don’t know - this might be an option the developers needs to consider to implement in the configuration?
But at all… this is a different topic and not related to the 2023.3 Dialog update discussion
risking posting one more off-topic reply regarding limited SD life on raspberry pi: rpis from 3b+ and on are able to boot from usb via an uption in the official imager. I’ve had great results using a Samsung Fit Plus 256GB 300mbit/s micro thumbstick (MUF-256AB) which has been much more reliable so far, and is even faster than the built in sd card reader when connected to a pi 4 usb3
You can already do this by going into the Setting → System → Storage and clicking on the three dots in the upper right corner and selecting “Move Data Disk”.
