Homelab Rebuild Part 6: Backups That Actually Work

The open gap Link to heading

Part 4 ended with a sentence I didn’t enjoy writing: there are no backups.

By now the Proxmox host runs a phone system, a RADIUS server, an internal certificate authority and an Ansible control node. I set all of it up by hand, some of it over several evenings. If that SSD dies, it isn’t “annoying” — it’s two weeks of work.

So before anything else gets added: the way back first.

The mistake I nearly made Link to heading

I’d already uploaded the Proxmox Backup Server ISO to the Proxmox host and created the VM before I noticed what I was doing.

A backup server running on the machine it’s meant to protect isn’t a backup server. If the host dies, backup and original die together. It sounds obvious written down — and happens anyway, because the Proxmox host is simply the box where you create VMs.

So PBS belongs somewhere else. In my case on the Synology, which runs anyway and ships a Virtual Machine Manager.

It isn’t a perfect setup: if the NAS dies, the backup server goes with it. But it’s a different box with its own power supply, its own storage and its own operating system — which is exactly the separation that matters.

Why PBS and not just dumps Link to heading

Proxmox can also write backups as plain files to a network share. That would have been quicker to set up.

The argument against it is space. A dump is a full backup every time. With five guests, a daily run and a few weeks of retention, that adds up fast.

PBS works block-based, deduplicates, and after the first run only stores what changed. In my case all five guests together came to 4.1 GB in the datastore. That makes seven daily, four weekly and six monthly snapshots completely unproblematic.

There’s also the way back: PBS integrates directly into the Proxmox interface, and restoring really is one click.

What went wrong Link to heading

Three dead ends, all while setting up the VM.

Black screen after installation Link to heading

The installation completed, and then the console just showed the last line of boot output. No login prompt, no reaction to keystrokes, CPU load under one percent.

I went looking at boot order, at BIOS versus UEFI, at networking. The cause was the emulated graphics adapter. Switched it to VGA and the prompt appeared.

The annoying part isn’t the fault, it’s the diagnosis: the system had been running the whole time, I just couldn’t see it. On a VM without networking the console is your only view — lose that and you’re completely blind.

dhclient doesn’t exist any more Link to heading

I didn’t want to nail the address down inside the VM, but hand it out centrally from the firewall. So I switched the network config to DHCP — and afterwards the VM had no address at all.

The reason was right there in the error: the system wanted to call /sbin/dhclient, and that program no longer ships with current Debian versions. Without networking you can’t install it either.

I put the static address back — and left it that way. On reflection that’s the better choice for an infrastructure service anyway: the backup server should be reachable even when the DHCP service on the firewall isn’t running. The reservation stays in the firewall regardless, as documentation and so nobody else gets that address.

The datastore on the wrong disk Link to heading

The VM has two virtual disks: a small one for the system, a large one for backups. I created the datastore through the obvious menu item, “Add Datastore” — and it landed on the system disk.

I noticed from the size: 27 GB instead of 200. Removing it then only worked from the command line; there’s no button for it at that spot in the interface.

The right route goes through Administration → Storage/Disks → Directory. There you pick the disk, format it, and a checkbox for “Add as Datastore” does both in one step.

This is one of those places where the obvious menu item isn’t the right one.

The part that matters Link to heading

Backup runs, schedule is set, retention configured. Done?

No. A backup that has never been restored is a guess.

So I tested it: picked one of the small containers, clicked restore, confirmed. Proxmox created it under a free ID automatically rather than overwriting the original — 1.2 GB in nine seconds across the network to the NAS.

Then started it, looked inside to check everything was really there, stopped it, deleted it.

That’s the difference between “I have backups” and “I know my backups work”. And it costs ten minutes.

The second half matters most: start it, don’t just restore it. A restore that writes files back but produces a machine that won’t boot has only given you half the proof. You’d find that out at exactly the wrong moment.

What’s still missing Link to heading

Both copies live on the same volume in the NAS: the datastore with the Proxmox backups, and the rest of my data. That protects me against the Proxmox host failing. It doesn’t protect me against the NAS failing.

On top of that, all of it sits in the same flat, on the same mains supply. That’s no help against water, fire or theft.

The plan against that already exists: an external drive as a second copy that normally isn’t even connected, and later an encrypted copy in cloud storage. That drive has a story of its own, though, which is worth a small detour — another time.

Next up Link to heading

The way back is in place. Now more can be added without every new service raising the stakes.

Next: the thing that makes VLANs usable over Wi-Fi in the first place — 802.1X with FreeRADIUS. A single SSID, and the network decides per device where it lands.

Part of a series about rebuilding my home network. As of August 2026. Questions, corrections and your own experiences are welcome in the comments.