Every dashboard in my rack could tell me what was happening right now — and not one could answer the question that actually keeps me up: if one of my four nodes dies tonight, do the containers it was running fit on the three that survive, and how long until they're back? I'd been answering that with a shrug. So I built a read-only simulator that reads the real cluster, does the arithmetic, and tells me plainly when the answer is no. On day one, it told me no.
Cross-post from Peira Labs. The full version — with the diagrams and the fifteen-line packer — lives at https://peira.dev/articles/homelab-capacity-planning-node-failure/
Plan against RAM you actually use, not RAM you configured
The configured memory maximum is a ceiling you picked once, usually generously. Plan against it and your cluster looks far more full than it is. Plan against a multi-day observed peak from your metrics and you learn what the workload really needs — while the configured limit still protects the host from a runaway process. Actual usage for planning, configured limits for safety.
"Just migrate it" isn't the recovery plan
Without shared storage, Proxmox HA can't restart a guest elsewhere — it can't reach the disk. On a local-disk cluster the real recovery path is a restore from backup onto a surviving node, so the only two questions that matter are: do the survivors have room, and how long does the restore take?
Packing the survivors: first-fit decreasing
Sort the homeless containers largest-first, then drop each into the first survivor it fits in. Sorting big-first places the awkward items while there's still room — provably close to optimal, which is far more accuracy than a homelab estimate needs. Fifteen lines of Python.
Restore time: measure once, then divide
Don't borrow someone else's number. Restore one real guest, time it, divide backup size by elapsed time to get your throughput. From then on, any restore estimate is just backup-size ÷ that rate. Your disks, network, and compression make a borrowed figure confidently wrong.
The scenario with no ETA
The nastiest case: the node that dies is the one running your backup server. You lose the fast recovery path along with the node — any backup stored only there is gone with it, and recovery falls back to whatever offsite copy you keep (hours, not minutes). It's the strongest argument for a second backup tier somewhere else entirely.
The simulator told me "no" on day one — one container that wouldn't fit anywhere, and a scenario with no ETA. Both were fixable once I could see them. If you want to run the same math on your own lab, I turned it into two free tools: the node-failure simulator and a blast-radius map.
Written by Peira Labs — full walkthrough with diagrams at peira.dev.
