Recovery is the only moment that actually matters in backup. Yet for most Proxmox administrators, the Proxmox restore backup process is something they follow for the first time during an actual incident, which is the wrong time to learn it.
This guide walks through the full proxmox restore backup process: restoring VMs from vzdump files via the web UI, restoring via the Proxmox Backup Server interface, restoring LXC containers, cross-node recovery, and common restore failures with their fixes. At the end, we cover what enterprise RTO targets look like and where PBS-native restore has limits that dedicated backup platforms address. For context on the full backup architecture, see the Proxmox Backup Server complete guide.
See How Zmanda Pro Simplifies This
Before You Start: What You Need for a Proxmox Restore
Before initiating any Proxmox restore backup operation, confirm you have:
- Access to the backup storage target (NAS reachable, PBS accessible at port 8007, local path mounted)
- Sufficient disk space on the destination storage for the restored VM image
- A VMID decision, restoring to the original VMID overwrites the existing VM; restoring to a new VMID creates a parallel copy (preferred for test restores)
- Network access to the restore destination node (for cross-node recoveries)
| Backup Source | Restore Method | Supports Cross-Node? | Granularity |
|---|---|---|---|
| vzdump file on NFS/local storage | PVE web UI → Storage → Backup content | Yes — if storage is accessible from target node | Full VM only |
| PBS datastore | PVE web UI → Storage → PBS content, or PBS web UI | Yes — any node connected to the same PBS | Full VM; file-level via PBS UI |
| PBS via CLI | proxmox-backup-client restore on PBS host |
With storage access | Full VM; individual chunks |
How to Restore a Proxmox VM from Backup (Web UI)
For restoring a VM from a vzdump backup file stored on NFS or local directory storage:
- In the Proxmox VE web UI, navigate to the left panel and select the storage target where the backup is stored.
- Click the Backup tab in the storage view. All backup files in that storage location are listed by VMID and timestamp.
- Select the backup you want to restore. Click Restore.
- In the restore dialog, configure:
- Storage: Destination storage pool for the restored VM disk
- VM ID: The VMID for the restored VM uses a new VMID for a test restore; use the original VMID to replace the existing VM
- Unique: Check this to generate a new MAC address for the restored VM (prevents MAC conflicts if restoring alongside the original)
- Click Restore to start the job. The task log streams in real time. Restore completion time depends on VM size and storage throughput.
- After restore completes, start the VM and verify application health before treating the restore as complete.
How to Restore a Proxmox VM from Proxmox Backup Server
PBS-backed restores follow the same UI path in Proxmox VE. The PBS storage target appears alongside other storage locations in the PVE storage panel. Select the PBS storage, open the Backup tab, and the available backups from that PBS datastore are listed.
PBS restores the benefit from chunk-level indexing. Because PBS stores backups as deduplicated chunks, it only downloads the specific chunks needed for the restore operation, not a full backup image. In practice, the oldest and newest backups restore at the same speed. There is no performance penalty for restoring a 90-day-old incremental backup versus yesterday’s backup.
PBS also supports file-level restore directly from the PBS web UI: navigate to the datastore, browse the backup catalog, select a VM backup, and use the file browser to extract individual files without mounting or fully restoring the VM. This is useful for recovering accidentally deleted files from a Windows Server VM without performing a full VM restore.
How to Restore an LXC Container from Backup
LXC container restoration follows the same path as VM restoration, with one key difference: LXC backups are in .tar.zst format rather than .vma.zst. The restore dialog is the same. Navigate to the storage, find the LXC backup (prefixed vzdump-lxc-), click Restore, configure the destination, and container ID.
LXC restores are typically faster than VM restores because LXC backups do not include a full disk image; they archive the container filesystem. A 50 GB LXC container backup restores significantly faster than a 50 GB KVM VM backup in most configurations.
Cross-Node and Cross-Cluster VM Restore
Cross-node Proxmox restore backup is one of the significant advantages PBS has over vzdump-to-NFS; any node connected to the same PBS instance can restore from the datastore regardless of which node created the backup. Any Proxmox VE node connected to the same PBS instance can restore from the PBS datastore regardless of which node created the backup. This makes PBS the right architecture for environments where node failure is the primary recovery scenario: back up from Node A, restore to Node B without moving files.
For vzdump backups on NFS storage, cross-node restore is similarly straightforward as long as the NFS storage target is accessible from the destination node. Add the same NFS storage to the destination node’s storage configuration, browse to the backup file, and restore.
Cross-cluster recovery, restoring a VM to a Proxmox cluster different from the one that backed it up requires either shared storage access or exporting the backup file. PBS sync jobs can replicate backups to a second PBS instance on a different cluster, enabling full cross-cluster recovery with PBS incremental efficiency maintained.
Restoring to VMware or Hyper-V from a Proxmox Backup
Native PBS restores the target Proxmox VE only. Cross-platform VM restore, restoring a Proxmox-backed VM to VMware vSphere or Hyper-V is not supported by native PBS tools.
This is a meaningful limitation for environments that run mixed hypervisor infrastructure, or that need to failover Proxmox workloads to a different hypervisor platform during a major incident. Enterprise backup platforms like Zmanda Pro support cross-platform VM restore natively, Proxmox VE backup with restore to Proxmox, Hyper-V, or VMware, which changes the disaster recovery architecture significantly for mixed-hypervisor environments.
Common Proxmox Restore Backup Errors and Fixes
| Error | Cause | Fix |
|---|---|---|
| Target storage has not enough space | Destination storage pool lacks capacity for the restored VM disk | Check destination storage free space before restore. Increase storage capacity or select a different destination storage pool. |
| VMID already exists | Original VMID is still in use on the target node | Either delete the existing VM first (if intentionally replacing it), or choose a new VMID for the restore to create a parallel copy. |
| Failed to connect to PBS (restore via PBS) | PBS unreachable at port 8007, or PBS storage not added to destination node | Verify port 8007 is open from destination PVE node to PBS. Add PBS as storage to the destination node if not already configured. |
| Restore job completes but VM won’t boot | Guest agent incompatibility, corrupted backup, or snapshot-mode backup without guest agent took inconsistent state | Run PBS verify job on the backup first. If backup is clean, check VM configuration — disk interface type, boot order, and BIOS/UEFI setting must match original. |
| Wrong MAC address causes network conflict | Restoring to original VMID restores original MAC, which conflicts if original VM still exists | Check the “Unique” option during restore to generate a new MAC address, or manually update the network interface MAC in VM configuration after restore. |
RTO Benchmarks and Where Native PBS Restore Has Limits
PBS restore performance is determined by network throughput between PBS and the destination node, and by the destination storage write speed. Practical benchmarks:
- 1 GbE network: ~80–90 MB/s — a 300 GB VM restores in approximately 55–65 minutes
- 10 GbE network: ~800–900 MB/s — the same 300 GB VM restores in 5–7 minutes
For environments with RTO requirements under 30 minutes for large VMs, 10 GbE connectivity between PBS and PVE nodes is the minimum required to meet the SLA.
Beyond network speed, PBS native restore has architectural limits for enterprise recovery scenarios: no automated recovery orchestration, no cross-platform VM restore, no centralized RTO monitoring across multiple clusters, and no integration with disaster recovery workflows that span application tiers. For environments where meeting documented RTO commitments is a compliance or contractual requirement, enterprise backup platforms provide the orchestration and visibility layer that PBS does not.
FAQs
