The Proxmox home lab
I am turning older computers into a controlled Proxmox environment where I can practise virtualization, segmented networking, storage, backups, monitoring, and service recovery through direct use.
Why reuse old computers
The project started because I wanted practical experience with virtualization and already had older hardware available. Reusing it gives each machine a purpose and gives me room to experiment without treating every mistake as a disaster.
The build order
I am treating the lab as a staged system rather than installing every service at once. The first stage is inventory: processor, memory, storage health, network interfaces, firmware, power use, and which machine can remain available for management. The next stages are the hypervisor, management addressing, storage ownership, isolated virtual networks, backup destination, and a known restore test.
Only after those foundations are understandable does a self-hosted service become useful. That order prevents a broken experiment from also becoming the only copy of its data or the only place where the recovery instructions were stored.
What I am building
The goal is a small environment for Linux and Windows virtual machines, separated services, networking tests, storage, backups, and resource monitoring. I am learning the setup by operating it, documenting assumptions, reproducing problems, restoring known-good states, and rebuilding parts when the first approach does not work.
- Create and manage virtual machines
- Separate services and test network boundaries
- Monitor storage, memory, and processor use
- Prove that backups can restore a service instead of only confirming that a backup file exists
- Find useful jobs for hardware that would otherwise sit unused
Network and recovery rules
Management, normal services, and intentionally vulnerable experiments should not share one unrestricted network. I want to observe and control the paths between them, restrict administrative access, and keep internet exposure off by default until a service has a documented reason and update plan.
A backup is not complete because a scheduled job produced a file. I want to restore a guest or service into an isolated location, confirm that the expected data and configuration return, record the time and dependencies, and update the procedure when the test reveals a missing secret or undocumented step.
Why it is useful
The home lab turns networking and systems concepts into something concrete. Instead of only reading about a configuration, I can deploy it, break it, observe the result, and repair it.
What I will document as it grows
The long-term record will include the hardware inventory, network diagram, addressing plan, virtual-machine purpose, resource allocation, service dependencies, backup location, restore evidence, notable failures, and the reason for each externally reachable path.
I will keep planned and completed work separate. A topology idea belongs in the roadmap; a working service belongs in the lab record only after it has been deployed, tested, and recovered in the environment described here.