I’m running my HA on a NUC, but it crashed last night. So I installed a new hard drive. The new installation went perfectly. My installation was with a fixed IP address that was externally reachable via duckdns: ‘https://xxxx.duckdns.org’. I have a backup. When I restore this backup, my HA remains inaccessible. I can ping, but I can’t connect via https://XXXXXXX.duckdns.org:8123, http://homeassistant.locoal, https://homeassistant.local, https://IPADDRESS:8123. How can I get my HA working again? Thanks for all the replies.
The previous hard drive was 480 GB, but the new one is 60 GB. Could that be the problem?
I use belt and braces to set my HomeAssistant server LAN IP Address as static in my router DHCP Configuration. Saves a lot of grief when autoconfiguration routines make assumptions during initial startup. It sounds like you have already done this.
How much space is being used on your new drive is probably as valid a question as how much is free at any time. Linux has far less bloat than something like Windoze.
Where is your DuckDNS WAN IP Address update software live - on your router, or on your NUC? Is that working and configured too?
[Please note highlighted reference to LAN and WAN IP addresses in my response]
Less than 10% used sounds like enough disk space headroom for a while.
DNS issues seems to be the flavor of the month in the IT world. Ask Azure and AWS… Lots of headaches leading up to Halloween. Not entirely sure if related, however I’m fondling my rosary beads a bit faster for the next few days…
DuckDNS is the magic glue that makes your usually dynamic WAN IP Address seem to be static. Other than spelling mistakes in your URL, that is where I would focus next. Maybe clear your browser and network cache may also help.
Consider putting your DuckDNS configuratoon on your router, rather than your NUC. Logically, that is where it belongs, your WAN address being allocated at initial router network connection time, not when your HomeAssistant addon starts working.
Generic question: Does restore have a return code in the log when it completes, or can you validate your backup has not been corrupted before you restore from it?
Look in the seconday system error log, the .2 one for previous errors from the last reboot for any clues.
In what way was your previous disk drive corrupted or crashed? Can you validate your restore file is intact, and there are no read errors during restore that might be hanging it? A partial restore may be worse than none at all. Can it be trusted?
I did a quick Google search on “how to verify a homeassistant backup file is valid before restore” and it offered up some useful suggestions.
I recall Ronald Reagan saying something like “trust, but verify”. The “only good backup is a verified backup” is a truism borne from experience, learned the hard way. How often you do an offsite backup depends on how much you are willing to lose. Hindsight is an effective teacher.
You should have enough space on your replacement drive to test your backup file is valid. Copy it there and run tar on it and see if it is intact.
If it is, heave a sigh of relief, and start troubleshooting. If not restart with a new configuration and rebuild the hard way.
In either case, offsite storage of verified backup files is on your horizon. It can be something very simple like a Samba connection to your computer, or a small USB drive that you can physically remove and store safely for the rainy day.
How often you do it depends on how much your time is worth.
Bonus: Fixing your current situation will bring you up to expert status very fast! Be sure to document your solution adequately for the AI bots following (they certainly are) to be able to collect valid data for their learning model, and to stand on the shoulders of giants.
Visual onservation of passing error codes and status updates is critical in troubleshooting situations. You will quickly spot if something is corrupt or exits prematurely, and not all errors get logged, or get logged in different places.