This has been stuck like this for 2 days now.
I thought I’d leave it and see what happens but it hasn’t shifted
So went to restart and it won’t let me until the backup finishes (which I’m confident isn’t going to happen!)
It also won’t let me reboot
So, how the hell do I get out of this backup cycle and kill that process?
I can understand checking that this is what you want to do, but actively preventing a reboot because an upload is stuck is not logical
Have you tried refreshing the browser cache? CTRL-F5 should do it.
Yeah, that didn’t work. Eventually got it to restart through the terminal, but you really should be able to a) cancel a backup and b) force a restart through the UI
I found have the same problem, its been running for days, finally had time to look and found this post
Was going to reboot the devise but started with this
ha supervisor restart
that fixed it for me, ran another backup and it appears fine
strangely it was only causing problems accessing add-ons, and pushing an update to a device
I’ve been having this EXACT same issue and it’s been driving me nuts. Restarting the supervisor/OS doesn’t help.
Any solution? Inhave the Same Problem
Best regards
The same symptoms for me. The nightly backup on June 9th apparently got stuck, the next nightly backup on 10th did not happen, and the history from devices was not recorded before reboot:
My backups are saved locally and to GoogleDrive.
I was not able to reboot from the UI, but was able to
$ ssh -l root homeassistant.local
[core-ssh ~]$ reboot
The processes before reboot looked like this:
[core-ssh ~]$ ps -ef f
PID USER TIME COMMAND
1 root 0:00 /package/admin/s6/command/s6-svscan -d4 -- /run/service
17 root 0:00 s6-supervise s6-linux-init-shutdownd
19 root 0:00 /package/admin/s6-linux-init/command/s6-linux-init-shutdownd -d3 -c /run/s6/basedir -g 3000 -C -B
26 root 0:00 s6-supervise s6rc-oneshot-runner
27 root 0:00 s6-supervise s6rc-fdholder
35 root 0:00 /package/admin/s6/command/s6-ipcserverd -1 -- /package/admin/s6/command/s6-ipcserver-access -v0 -E -l0 -i data/rules -- /package/admin/s6/command/s6-sudod -t 30000 -- /package/admin/s6-rc/command/s6-rc-oneshot-run -l ../.. --
155 root 0:00 s6-supervise sshd
157 root 0:00 s6-supervise ttyd
158 root 0:00 sshd: /usr/sbin/sshd -D -e [listener] 0 of 10-100 startups
159 root 0:07 ttyd --writable -p 8099 tmux -u new -A -s homeassistant bash -l
198 root 0:00 {tmux: server} tmux -u new -A -s homeassistant bash -l
199 root 0:00 bash -l
304 root 0:00 sshd: root@pts/0
306 root 0:00 -bash
319 root 0:00 ps -ef f
Same hrere.
I have also been having this problem since April. I’ve been running in a guest VM (to avoid issues with power etc), but that seems to not be enough. I have had to force destroy the VM to “reboot”, and the back ups NEVER complete. There hasn’t been a successfully completed back up in almost two months. I’m trying to move to a dedicated RPi5 to see if that helps, but now I’m getting an error 500 from the RPi5 trying to upload the TAR.
I have the same issue, mine is a VM in Proxmox and a restart has not fixed it.
I suspect it might be one of the add-ons messing up, here are the ones I have:
# ha addons | grep "name:"
name: File editor
name: Studio Code Server
name: Home Assistant Google Drive Backup
name: ESPHome Device Builder
name: InfluxDB
name: Grafana
name: Samba share
name: Terminal & SSH
name: Matter Server
name: Music Assistant Server
name: Linky
name: YT Music P0 Token Generator
Thanks
Raphaël
I also have the issue, only started recently. I had to restart the Proxmox and reload it again
Thanks
Fwiw I’m fairly convinced this issue is caused by a “bad” internet connection during backup
I can’t say specifically what, but I replaced my routers recently and haven’t had the issue since
I recently upgraded from a Unifi UDM to a UDW I do not think it is a connection issue. But my logs do have some interesting items in it.
I’ve been experiencing this too. I didn’t realize it was even happening until one day I needed to restart home assistant but it wouldn’t let me. I can’t believe this hasn’t been fixed yet. I’ve always had automated backups until a couple of months ago when I installed home assistant on a new faster computer. I didn’t enable auto backups until I got everything setup and working good again. That’s when I noticed the backup was frozen. My backup file is only about 140MB in size and it literally takes less than 30 seconds for the backup to complete on my machine.
I just had the same issue with a manual backup. It was stuck “uploading” for ~30min and I couldn’t reboot the system. The ha supervisor restart command above did not resolve the issue for me; had to do a full system reboot 
Seems like this is a real issue that needs to make its way into the product backlog.
Steps I have linked above is what works.
I just had this happen for the first time since switching over to the new built-in automated backups, but it used to happen to me approximately every other week when triggering them with an automation. I’ve been unable to find any logs or other indication of problems across many months.
I used to solve this via just rebooting my Yellow, now this requires dropping into ssh and doing an ha core restart (supervisor refuses since the system is in the frozen state for the backup). The core restart causes the backup to enter the failed state so I can then reboot.
Both with the old automation-based backups and the new built-in, when this problem occurs the system load average skyrockets from my usual < 1 to above 3. I actually have a “high system load” automation set up to alert me when this happens, since it is a reliable indicator of this situation happening overnight (these days I could switch to the backup manager sensors, but I digress).
The high load average persists even after the ha core restart, though the rest of the system appears to function normally. In my brief poking around this morning, I didn’t even notice any apparent slowness despite the high load. This leads me to the following conjecture:
I haven’t been able to prove anything, but long ago I had an issue on my home server which manifested in this same way: high load average until reboot. It ended up being a stuck NFS mount causing processes to become stuck in permanent iowait. I’m wondering if something similar is happening here with the SMB/whatever connection dropping and the backup being in a sort of filesystem limbo. Or perhaps it’s related to the overlay filesystems used by the addons, but a similar result.
If anyone has any ideas about how to track down the state of the kernel when this happens, I’d be happy to test some of them out next time I wake up to this. With how containerized HA is I don’t have much experience with debugging it further down.
Edit: here’s the visual indicator of this happening, I’d be curious if the same happens for any of you:
I will check my system load next time it happens to me. It was the 20 July 2025 when it last happened, I have had three such events.
The logs from my system at the time are here.
It would be good to get to the bottom of this intermittent issue that is obviously affecting some instances.
I run HA On a Home Assistant Blue ODroid N2+ if that has anything to do with it.
This happened to me numerous times, too.
For me it always happened, when my network backup location ran out of storage (my router has an option to create a SMB share from a plugged in USB drive, which I used as external backup location because Home Assistant can’t handle my NAS being shut down over night).
A simple reboot usually fixed it but somewhere between 2025.08 and 2025.10 Home Assistant got the “feature” to not reboot until a backup is done, which is generally a good idea but is a problem when the backup process gets stuck.
As reported by others ha supervisor reboot is blocked by freeze but ha core reboot worked for me. Afterwards a supervisor reboot via CLI or GUI is possible again. There should be a better way to handle this.
For me the initial issue was resolved by setting backup retention to a much lower number.
