Proxmox Backup Lab
Context and motivation
I built this lab to practice the operational side, backing up and verifying, not just configuring.
Ansible manages the Proxmox hypervisor through its API and defines the whole lifecycle as code, idempotently. It creates the isolated network bridge, a Debian cloud-init template and clones three VMs that talk to each other, an internal DNS with bind9, a web server with nginx and HTTPS, and a file server with Samba.
The layer that gives the project its name is backup and recovery. A vzdump job backs up the three VMs with retention, and a pair of scripts cause a disaster on purpose, they completely destroy a VM and restore it, checking that it boots again with its IP, its data and its service intact.
Technologies
Main features
- Proxmox VE hypervisor managed through its API with Ansible, idempotent end to end
- Isolated internal network (vmbr1, 10.10.10.0/24) with NAT, created by code
- Debian cloud-init template and cloning of three VMs
- Internal DNS with bind9, web with nginx and HTTPS, and file server with Samba
- Full-VM backups with scheduled vzdump and retention
- Disaster scenario that destroys a VM and restores it, verifying IP, data and service
- Runbook with the recovery procedures documented
Gallery
Conclusion
It's a lab environment and I say so in the repository. The hypervisor runs nested on VMware Workstation, there's a single node and the API token credentials live in a secrets file outside version control.
What I really take away isn't setting up the services, it's closing the loop. Making a backup is one thing, causing the loss on purpose and proving, with a script that verifies it on its own, that the data comes back is another. That's the stamp of the project, back up and verify.