Loading...
E.G.

Rebuilding Home Assistant From Backup: a Timed Run

August 12, 2026
Table of Contents

Why I ran it at all

I had daily backups for a long time without ever restoring one, which meant I had a process I believed in rather than one I knew about. So I built the host again from scratch on a fresh VM and timed each step.

It took about fifty minutes. Two of the steps aren't in any backup archive, and both of them stop the restore until you work out what's wrong.

What the run looked like

The rough shape, with the times I measured:

New VM — about 5 minutes. A plain Ubuntu instance, two vCPUs and 4 GB of RAM, which is comfortable for Home Assistant in Docker.

Download and transfer the archive — about 5 minutes. Pulled from the offsite storage container to my laptop, then copied up to the new machine. Doing it directly from the VM would be quicker, but that needs the machine identity to exist first, and at this point it doesn't.

Docker and Home Assistant — about 10 minutes. Install Docker, unpack the archive over the filesystem, start the container. This is where the docker inspect JSON in the archive earns its place: the exact image, network mode and volume mounts are in a file rather than in your memory.

WireGuard and the firewall — about 5 minutes. Both configurations come out of the archive. If the new machine has a different public address, the server config needs that one line changed.

Machine identity and network rules — about 5 minutes. See below, this is the part that isn't in the archive.

Client configs — about 10 minutes, and only if the address changed. Every VPN client needs the new endpoint. This is manual on each device and it's the step most likely to be forgotten, because the restore looks finished without it.

Verification — about 10 minutes. Covered further down.

The two steps that aren't in any archive

The backup script uploads under the VM's own managed identity, so there are no credentials in it. That's the right design, and it has a consequence at restore time: a new VM is a new identity. It has to be granted again, and the storage container has to be told about it, before that machine can reach its own backups. On the first run I hit this before I'd worked out what was happening.

The second one is the network security group. It's attached to a network interface, and a new VM has a new interface. Until the group is attached, the machine is either unreachable or open, depending on the defaults, and neither is what you want.

Both of these live in the cloud provider's control plane rather than on the disk, which is exactly why no file-level backup contains them. They belong in the recovery document instead, which is where I put them after this run.

Verifying it actually worked

A container that starts is not a restored system. The checklist I use now:

Home Assistant answers on its port and the web UI loads. The dashboards render rather than coming up empty, which is the tell for a missing .storage directory. KNX devices respond, so the bus connection came back. The cameras appear. Solar and PV figures are arriving, which means the Modbus reads reconnected. WireGuard shows its peers and the clients connect. The firewall is active. And the backup cron job is present and its next run will actually upload, which is easy to forget on a machine that was only just given permission to do so.

That last one matters more than it looks: a restored host that isn't backing itself up is a system waiting to have the same problem twice.

What changed afterwards

The run changed the recovery document rather than the backup script. The archive turned out to be complete. What was missing was the knowledge that two control-plane steps sit between having the archive and having a working host, and that knowledge only exists if someone writes it down after doing it.

If you want the other half of this, what goes into the archive in the first place is a separate post. The host itself is set up step by step here, and taking a backup before a routine update is a different job with its own rhythm.

Summary

Run the restore once while nothing is broken, and time it. You get a number you can plan around, you find the steps that live outside the backup, and you end up with a recovery document that was written by someone who had actually done it.

Related articles