It is a process problem. It takes far less time to restore manually the core component.
If you search Github for one of the issues which was created regarding the slow restore, then you will find a description how to manually restore core in 5 minutes to a working order.
aha… sound great, but… there’s over 2000 “cases” for core alone… do you have some links by any chance?
If you think using the search for me is easier than for you, then you are absolutely wrong! And you should do a favour!
Well, that depends on your and my knowledge of english, resulting in finding correct words for searching…
Thanks for the link, although it’s more for cases when HA doesn’t work anymore, not for cases when it works, but a person wants to go back for various reasons (like one integration not working after update). And it’s hardly 5 minutes of work… just reinstall HA takes more than that. But, it’s less than 4 hours, that part is true.
You must be a mathematician!
You can restore core by reverting the image to an older one (which you wanted to restore) and restoring the files through the ssh addon from the backup. You don’t have to reinstall HA.
But all it is an overcomplicated manual process which I do not advise, unless you really know what you are doing.
Until the issue is fixed. You should stay with restoring backups the official way!
Yeah, luckily it doesn’t happen often. Although i never reverted HA manually i did “go back” once or twice “official” way, i just ran restore before going to bed and in the morning all was ok. I do some basic linux stuff every now and then, but that’s all. I agree, it’s complicated and easy to do even more damage.
(and, sorry, not mathematician, true electronicyst…)
It meant to be a reference to a classic joke:
A physicist and mathematician are tasked with making tea, they’re provided with a kettle, a water tap, stove and tea leafs each.
They both fill up their kettle, put it on the stove to boil then add the tea.
The next day they are tasked with the same but provided with an already filled kettle.
The physicist goes about with boiling the water but the mathematician simply dumps out the water from his kettle and exclaims “Now we we’re back to the hypothesis of the first problem which was previously solved!”
Unexpected surprise:
But all was OK! No missing integrations, devices or Lovelace setup, all there. Seems like the restore was finished (ok?) but “forgot” to tell the busy-restoring notification in the browser.
It’s still fresh, so maybe something will pop up later. And/or maybe this N=1 is a pure coincidence…
Well, I’m a bit late to the party, but your [vdrHorst] reply helped a great deal, thanks!
tl;dr: Refreshing the page after a long restore wait immediately showed completion.
Had installed HA image (via RPi Imager) and played a bit (newbie) on one RPi. Decided to use another, and a different SD card, for a more permanent installation.
Opened the :8123 port using my laptop browser.
Made a backup from the first RPi, 6.5MB. (Yes, “MB”)
Imaged the new sd, booted the RPi, waited till initialization finished. Selected “restore from backup”, gave it the 6.5MB .TAR file. Waited. Wondered. Found my way here, and read through the entire thread, to the prior post.
After reading about powering off his Pi, I wondered… and hit [F5] on the tab for homeassistant.local:8123, which was still showing the chasing circle after ~45min.
And immediately got the expected “overview” page with all devices (apparently).
So it appears that, in this case, restoring a 6.5MB .TAR file to a new Home Assistant SD image on an RPi4, the “restoring” screen chasing circle never updated (~45mins) until I refreshed the webpage. And now all looks right.
Thanks again to all!
That seems like a bad idea, a cheap ssd is still beter than a expensive sd
Depends on the hardware I guess. The USB3-SSD that I used didn’t work well with my RPi4. When RPi4 is physically rebooted I usually have to manually unplug the USB and re-plug back in for it to boot into HA. I failed to find out why and couldn’t bother using it anymore.
Maybe USB SSD isn’t a good idea. I don’t know.
I’ve had exactly the same thing happen to me, “hung” on restore screen until I refresh my browser. I wonder if it’s a “browser thing”
It’s definitely a browser time out of some kind. The backup/restore routines should push a refresh to the browser. It apparently doesn’t. I get the same often, on backup or restore. I use iotop to monitor when it’s done. My backups are over 400MB and it can be painfully long. 120 minutes plus for restore! Even using a SSD on RPi4/8GB.
There are at least four issues outstanding.
Problem: Backups just fail silently (usually immediately), which manifests as it taking hours to fail when in reality it usually never actually started. I suspect this is what most people here are facing.
Workaround: Periodically refreshing the page seems to be fine. If you see the restore backup page again after a refresh, your restore has failed and you will need to investigate further.
Solution: I have described the issue of needing to refresh the page once the restore is completed here and proposed a fix here too.
Problem: If your backup was created using a newer supervisor (2023.12.1) than what is pre-installed on your new HA install (2023.12.0), your restore will fail.
Workaround: I wouldn’t recommend it but strictly speaking it is possible to modify the backup.json file instead your backup archive. I did this and experienced issues with some of my add-ons reinstalling because there was changes in the way that the supervisor stored config data in a future version. Again, downgrading your backup isn’t recommended.
Solution: The supervisor needs to automatically install the latest version when restoring a back-up but doesn’t. An issue has been raised for this.
Problem: Even if we did show the error message from the API when a restore fails, that error most often is just “unknown error”.
Workaround: You will need to check the supervisor logs. Unfortunately, this just isn’t always possible, i.e. with headless devices, like a Raspberry Pi stored in your networking cupboard.
Solution: The Onboarding API should have a way to check the supervisor logs. A new issue or PR will need to be raised for this.
Problem: It seems like the HTTP server goes down during a restore. This can look like the restore failed but it’s usually fine and you just need to wait a few minutes.
Workaround: You can check the supervisor port if the install is still healthy.
Problem: There is no handling currently for when the server is down during the restart in the Front end or Supervisor APIs to update the progress. It should be something like a “Restarting… Please wait 5 minutes.”-type message. A PR has been raised for this.
For me it worked to just reboot the system 30 minutes after the restore started. Then, HA booted normally with the backup fully restored. Probably you can already reboot after 5 minutes, my guess is that the restore does not really take very long, it just does not show that it is finished.
I did have a small backup (1 MB) and run Ha on an old laptop, which peforms much faster than the R-Pi4
Looks like there should be significant fixes to the backup / restore processes in 2024.2 with some of the latest changes that have gone in.
The first time I tried to restore from a backup I let it run and it was still showing the “in progress” spinner 24 hours later.
This link helped ease my doubts:
https://www.derekseaman.com/2023/04/home-assistant-pt-3-restoring-your-configuration.html
Here is a quote from the article:
Waiting on the the Restore to Complete
At this point the Home Assistant UI fails us. There is ZERO feedback on if the restore is working, if it failed, or had errors. And you have no idea when it is done. The Restore in progress window remains, even after the restore is complete. Huge fail. For reference, I restored a 1GB HAOS backup and it was completed (per Proxmox stats) in about 10 minutes. But 40 minutes later the Restore in progress window was still there.
If you are restoring HAOS on Proxmox, once the restore starts, flip to the VM Summary screen and monitor CPU, network and disk activity. After things quiet down, proceed. See the screenshot below for what the performance stats of my HAOS VM looked like during the restore process.
After you think the restore has finished, refresh your web browser and see if you get a regular Home Assistant login box. If not, the restore is not yet complete or it failed. Wait a few minutes and try again. If your production HA server was using SSL certificates, then before you refresh your browser change the URL to use HTTPS. If you don’t do this you’ll be sitting there all day refreshing even if the restore is complete. You may need to open a new browser window to get the refreshed HA login page.
the person in the comment above you made a number of PRs to fix many of those restore issues. They wrote a post with a full run down of their PRs, etc a few comments above that: How long should a restore from backup take? - #50 by codyc1515
After a power breakdown HA stayed in recovery mode. I restored to a older backup form 1.5GB and that took about 30 minutes. Now I’m trying to restore to the latest backup from 22GB big (I know way too big, it also contains all the recordings from my recently installed frigate) but now after 7-8 hours it’s still not finished. Must I wait a little longer or try to reboot my nuc?
| Supervisor: | Connected |
|---|---|
| Supported: | Supported |
| Healthy: | Healthy |
Since this topic has started many things has changed in HA regarding how Supervisor deals with the backups, but seems to be still an issue the restore process, disregarding that it has had some upgrades added to it, to speed up the process. If you struggle with the large backup, then I would suggest a manual way if you are techy enough to do so. See my post above referencing a Github issue how to copy things manually from the archive.
I think the only thing which I did a bit differently then the instructions is that I started HA and the addon, and when I have made sure that the addon is running, I shutdown HA from the terminal to do not interfere with it when overwriting the files.