A Proxmox backup is only useful if you know what it restores, where it restores, and how long the restore takes. For small hosting labs, agencies, and internal IT teams, the safest backup plan is a verified restore plan.
This checklist focuses on practical verification. It is not tied to one emergency advisory or one Proxmox release. Use it as a recurring operations routine for Proxmox VE and Proxmox Backup Server environments.
Confirm what is actually protected
Start with inventory. List the VMs and containers that matter, then confirm each one has a current backup job and a clear restore target. Do not assume that a backup schedule covers every workload just because the job name sounds broad.
For each important VM or container, record:
- Backup schedule and retention policy.
- Backup storage target.
- Whether the workload is crash-consistent or application-aware.
- Whether databases, mail queues, uploads, and customer data live inside the guest or on attached storage.
- Which services must be checked after restore.
- Who approves a restore during an outage.
Separate backup success from restore confidence
A green backup job is a starting point, not proof of recovery. The job may have copied data successfully, but you still need to know whether the guest boots, services start, storage mounts, and customers can use the application.
Use a low-risk test restore routine. Restore into an isolated network or test host, keep it away from production IPs, and verify the workload without letting duplicate services talk to live customers. For web-hosting workloads, confirm the site loads, database connections work, mail or queue services do not accidentally send duplicate messages, and application logs do not show missing mount points.
Check retention before you need it
Retention should match the failure modes you actually worry about. A daily backup is not enough if ransomware, bad imports, or accidental deletes are discovered days later. A long retention period is not useful if storage fills and jobs start failing silently.
Review retention for:
- Accidental file deletion.
- Bad plugin or application updates.
- Database corruption.
- Compromised accounts.
- Failed migrations.
- Storage or host failure.
Then confirm that your backup storage has enough headroom for the retention policy you wrote down.
Verify storage and cluster assumptions
In a Proxmox cluster, backup verification is also a cluster operations task. Confirm where a restored workload can run if one node is down. Check storage compatibility, network bridges, VLANs, firewall rules, and any HA expectations before an outage.
If the workload uses shared storage, confirm the restore target can see the same storage or has a safe alternate path. If the workload depends on local disks, document which node owns the data and what happens if that node is offline.
Keep a short restore runbook
The runbook does not need to be complicated. It needs to be usable when everyone is tired:
- Where backups are stored.
- Which restore target to use first.
- Which network should be isolated for test restores.
- Which services prove the restore worked.
- Which customer or internal contacts need an update.
- How to avoid starting duplicate production services.
- How to roll back if the restored copy is not usable.
Schedule a restore test after major Proxmox upgrades, storage changes, backup server changes, or workload migrations. That is when hidden assumptions usually break.