I’m setting up a new HA installation. I have a working HA system running on a multipurpose linux box, and I want to set up a new machine running HAOS.
I’ve got the basic install done, and I’m working through the onboarding. I’m trying to restore from a backup of the existing system rather than set up all the configuration again.
When I start the restore, it says ‘Uploading’ for a long time but nothing seems to hapen. If I look at the logs with core log -f -v --log-level debug, I’m getting errors that it can’t PING a WLED device, but no output related to the backup restoring at all. Sometimes the frontend gives an error that that backup task is busy (Can't upload backup file: Backup manager busy: receive_backup ) but it mostly just seems to sit there doing nothing. I’ve left it there for over an hour a couple of times - perhaps its working but really slowly? The fact it’s pinging a WLED device suggests it’s installed some bits of the backup, as I don’t think that’s there by default?
Is there any way to get more info about what’s happening and why I can’t restore from backup? Would it be better to set up a clean install and then restore the backup to that?
I’m using HAOS v 17.1 + HA 2026.2.3 on the new machine, running core 2025.4.4 on the old machine.
I’ve seem BIG files take much longer than you’d expect to restore - my own error was to add media files to HA for streaming. Restore would have taken days, but there is a workaround.
The good news is a HA backup is just a a tar gzip of component TGZ files so you can manually ‘unpack’ the old backup, look at the contents down to individual file level and restore in stages (e.g. unpack, edit, repack, test restore).
So, if the file is big (years of grafana sensor data?), it can be taken apart, and only parts restored.
(Some backups are encrypted, but there are tools to decrypt this - I configure HA to NOT encrypt local backups to avoid this.)
My own fix was to expand the TGZ, remove the audio files, then re-TGZ. The backup worked fine.
Mine are about 300Mb, so size doesn’t seem to be the issue.
Can you create a non-encrypted local backup and try renaming it with .tgz and looking inside the archive?
I’ve restored just parts of HA before - .tgz within .tgz, or even just pulled out YAML to revert something.
The classic restore issue isn’t the restore itself, but fixing static IPv4 / DNS / mDNS issues where clients can’t locate the new production HA instance.
The phrase multipurpose linux box could be hiding a lot of VM/hypervisor/container complexity that even as a greybeard sysadmin, I just can’t face.
Have you a spare box to try a HAOS bare-metal install?
A RPi4/5 is my go-to cold spare for dev/test/pre-prod.
I’ve had a look inside the archive, but not sure what to look for really. The new install is a bare metal HAOS install for exactly the reasons you’re stating.
I’m looking forward to some afternoons of telling all the Tasmota devices the address of the new server, but surely that shouldn’t hang a restore? And surely there should be some way to figure out what it’s hanging on?
Maybe I should do a clean install, and then try to restore just scripts, blueprints and automations once its up and running? Bit of a pain, though!
Ah, I see - bare metal HAOS should rule alot of problems out.
Beyond restoring just individual component backups (never seem docs on this, but the TGZ names are reasonable), I’m going to suggest leaving a full restore overnight.
First install can seem to hang as it looks up DNS and pulls extra components down, but ISTR restore is past that?
Some folks have reported DAYS to restore, but 100Mb doesn’t seem excessive.
Perhaps try a Debian/ Fedora install as a test to see if the storage is OK?
Yeah, it’s definitely done some amount of pulling in components etc. If I look at top, nothing is using CPU. It’s also pretty strange that nothing shows up in the logs - surely there should be some output around restores? I can try letting it sit there for a couple of days.
And this backup you are trying to apply to your NEW 2026.2 Install ,IS from the Old Machine 2025.4 ?
You do know that “sometimes” “Breaking Changes” sneaks their ways into Updates, This Could potentially be The Reason, As it’s Not only about 1 year old CORE, Supervisor And frontend is kind of Updated to, OS 17.1, is diffidently New, And in some Components etc, there are "requirements & Dependencies " … Which You are now trying to “Dump”
You already Spend quite some time “Trouble-Shooting” Your “Approach” of trying to “save times” … Worth it ?
Beside, Having i.e 2 homeassistant.local:8123 on same network, WITH the same Devices/Integrations/APPs(Add-Ons), IS abit of a hassle ! , If you know what i mean
Thanks, yes I realise they are different systems. Also - the original system has a different hostname, so that’s not an issue (although it’s going to be a pain changing it for a bunch of Tasmota devices…).
As far as I know, though, my approach is the recommended way to do things. I’m not trying to be particularly sneaky or clever, I’m following the installation guide.
So if the advice is to trash it all and start again, fair enough. If it’s possible to set the new system up with the hardware etc. and then restore scripts, blueprints etc. that would be great - but I suspect it gets pretty fiddly. It could also be that it’s worth putting time into upgrading my current install.
WIthout any debug output, it’s hard to figure out what the best plan is.
Yes, All Yaml, scripts etc , And even Integration/Apps Settings, Automation, blueprints Etc, is possible to apply manually, But you’d be better of installing the Integrations and Apps from scratch
You could I.e, try 1 by 1, Updating, The Integrations/Apps, and apply their “Configs”
But as James above Mention i.e The DB, And Overwrite Old Data, Could cause it to “spin” internally.
So Save your DB-file, and take that Part, after you get your system up and running again ( It’s just another Time Consuming Task ) Like above
PS: Take Your Other (old)HA Offline while getting your New up and running, regardless whether it has another name/ip
Some(many) Devices simply wont work/exist on 2 Running instances
NOTE: If you are familiar with HA CLI i suggest you do the “Restore” from there, and turn of your browser Initially, try first with the DB, thou you might end up doing it without
If Your not familiar With HA CLI , type --help, and after each command --h.
You should only be able to read, in a structured approach
Almost forgot, ofcause you can also read i.e tail - log-file in the cli after executing i.e update commands , and set debug etc In the Cli
So I’ve copied certain files by hand. Hinky, but it’s a least gotten me close to restoring my setup.
I’m working through this - have a new HA set up with all the integrations etc. and I’m trying to restore just the automations, scripts, scenes, config and core.config/devce/floor etc. files. I’ve opened up the backup, removed all the bits I don’t want, recompressed with the same format etc. and uploaded to the backups on the new server.
But:
I can’t see a way to use a partial backup in the Web UI. I could be missing something?
If I use my unencrypted, passwordless backup in ha CLI, it says “Invalid password”
If I try to do it by hand in the linux shell “ha login”, I can’t see how to create a mountpoint and mount a USB stick as the root filesystem is read only and fstab isn’t there.
All “txt” files, .Yaml , .Json , etc. You can just copy-paste No reason to use backup for this
COPY All And Paste
PS: Thou the core.config/config-files beside config.yaml you should “not” .
You have to be Very Careful when even “touch’ing” them !
If you shut down core, you could “replace” them, if you are Sure they are not to “outdated”
Thanks! Replacing the files went OK. It was really the device bindings that I wanted to get straight, so I did that by replacing some of the core.X files. The Dashboards didn’t work, but did when I copied the YAML in.
Yeah, i forgot, the dashboard backups are in json format, and registret in lovelace_dashboards etc . so actually as easy to create new and replace in YAML-mode in ui
I used below before, to restore Dashboards Transform JSON into YAML - Online YAML Tools .
this post!