Cluster recovery / May 10, 2026
Restored Proxmox quorum after a switch migration interrupted two node paths, verified all three nodes, then saved and documented the corrected switch state.
02 / Infrastructure / networking
Operating a segmented three-node homelab
My homelab grew from one server into a three-node Proxmox environment with managed switching, separate network zones, identity, monitoring, storage, and recovery notes.
Starting point
Where it started
The lab had outgrown a flat network. Management, storage, identity, public services, guests, and monitoring needed distinct trust boundaries without losing the ability to recover when a migration went wrong.
What I did
What I worked on
- Designed role-based network zones and migrated services in dependency-aware phases.
- Reworked managed switching, firewall policy, DNS behavior, reverse-proxy paths, and remote access.
- Recovered cluster quorum during a switching migration and captured validation and rollback checks.
- Built a source-of-truth documentation system for inventory, services, decisions, incidents, and public-safe exports.
Evidence
What I checked and recorded
Guest network repair / May 26, 2026
Corrected an OPNsense captive-portal interface binding, removed stale bypass sessions, and validated the repaired path with a fresh mobile connection.
DNS migration / May 31, 2026
Moved client-facing DNS to Technitium, updated DHCP resolver assignments across VLANs, and documented the split-horizon and upstream resolution path.
Result
What changed
The environment now has clearer boundaries, visible service dependencies, defined backup roles, and an operational record that survives the next troubleshooting session.
What I learned
What I took from it
- Migration order matters as much as the final architecture.
- DNS and identity failures often present as application failures.
- A recovery path written before a change is more useful than a perfect diagram written afterward.
Next case study / 03