Proxmox VE Backup Restore Drill

A backup you have never restored is a hope, not a recovery plan. This blueprint runs an automated Proxmox VE disaster-recovery drill that proves your vzdump backups are actually recoverable, without ever touching production. It lists the backup archives on a storage, restores a chosen archive to a throwaway VMID, probes the restored virtual machine to confirm it boots and responds, then deletes the test VM so each drill leaves no residue. An error handler tears down the test VM even when verification fails, so repeated drills never accumulate orphaned machines on your Proxmox cluster.

How it works

1. list_backups (io.kestra.plugin.proxmox.backup.List) enumerates the vzdump archives available on the source storage.
2. restore_backup (io.kestra.plugin.proxmox.backup.Restore) restores the chosen archive volid to the target_storage under the throwaway test_vm_id, with resourceType: VM.
3. verify_restore (io.kestra.plugin.core.http.Request) issues a GET against verify_url to confirm the restored VM is healthy and reachable.
4. cleanup_test_vm (io.kestra.plugin.proxmox.vm.Delete) removes the test VM so the drill is non-destructive and self-cleaning.
5. On any failure, the cleanup_on_failure error handler (io.kestra.plugin.proxmox.vm.Delete) deletes the test VM anyway, preventing orphaned machines.

What you get

• Continuous, evidence-based proof that your Proxmox backups can be restored.
• A fully isolated drill that runs against a throwaway VMID and never affects production VMs.
• Self-cleaning runs: the test VM is deleted on success and on failure.
• A repeatable, auditable recovery procedure captured as version-controlled YAML.

Who it's for

• Infrastructure and platform engineers running Proxmox VE clusters.
• Site reliability engineers who need to validate recovery point and recovery time assumptions.
• Teams with compliance or audit requirements that mandate tested backups.

Why orchestrate this with Kestra

Proxmox can schedule backups, but it does not orchestrate restore validation, cross-check the result with an HTTP probe, or guarantee cleanup when a step fails. Kestra adds a Schedule trigger for recurring drills, retries on transient API errors, full execution history and lineage across the list, restore, verify, and delete steps, and a declarative YAML definition you can review and version. The error handler closes the gap Proxmox's own scheduler cannot: deterministic teardown of the test VM regardless of outcome.

Prerequisites

• A reachable Proxmox VE host and an existing vzdump backup archive volid to restore.
• A free, unused VMID in the cluster to assign to the restored test VM.

Secrets

• PROXMOX_HOST: Proxmox VE host or IP (no scheme, no port).
• PROXMOX_NODE: Cluster node name that scopes the API calls (for example, pve).
• PROXMOX_USERNAME: PAM or PVE user in the form user@realm (for example, root@pam).
• PROXMOX_PASSWORD: Password for ticket-based authentication.

Quick start

1. Set the four secrets above in your Kestra namespace.
2. Run the flow with the archive volid, target_storage, test_vm_id, and verify_url.
3. The flow restores the backup, verifies it, and deletes the test VM, leaving no residue.

How to extend

• Enable the disabled weekly_dr_drill Schedule trigger to run the drill on a cadence.
• Replace the HTTP probe with a deeper smoke test (service login, query, file checksum).
• Notify Slack or open a ticket when verification fails, before the cleanup runs.
• Loop over multiple archives to validate a whole set of VMs in one execution.

Links

• Plugin docs: https://kestra.io/plugins/plugin-proxmox
• Orchestrate Proxmox with Kestra: https://kestra.io/orchestration/proxmox