Learn Proxmox Backup Server - Restore VM/CT & File-Level Recovery

#Introduction

After backups run routinely in episode 4, now we talk about why all of it is done: recovering data. A backup without a tested restore is merely an illusion of security — and ironically, most admins only realize the mistake when disaster strikes. Episode 5 trains you to perform full restores and file-level recovery in the lab, so when production goes wrong, your hands already know the steps.

Imagine a backup like a time capsule: episode 4 is storing it, episode 5 is opening it and making sure the contents are still usable. There is no point storing a capsule if its contents are damaged when opened.

#Full VM/CT Restore

#Restore to the Same PVE

A full restore means rebuilding the entire VM/CT disk from a PBS snapshot. In the PVE web UI: VM → Backup → select snapshot → Restore. Fill in:

Target storage: the PVE storage where the VM disk will be placed (e.g. local-zfs).
VM ID: a new ID if the original ID is still in use.
Unique name: the new VM name.

PBS restore uses the sparse mechanism: zero blocks are not allocated and restore starts immediately while data is still streaming. For large VMs, you can boot the VM before the restore finishes — PVE offers this option in the GUI PBS restore (a "start after restore" feature in certain contexts).

#Restore to a Different PVE

Because PBS snapshots are self-contained (they store all data + VM config metadata), restore to a different PVE node, or even a brand new PVE cluster, is a standard operation. This is the basis of cross-site disaster recovery:

Register the same PBS (or the sync result from episode 10) as storage on the new PVE.
Open VM → Backup → Restore, choose the desired snapshot.
Choose a local target storage on the new PVE.

Make sure the new PVE has storage with enough capacity — restoring to a smaller storage will fail.

Important

Restoring to another PVE requires a target storage with enough space and, for restore to another cluster, the appropriate PBS access rights. If the snapshot is encrypted (episode 7), the key must be available on the side performing the restore.

#File-Level Recovery

#The Concept: Restore Without a Full Restore

Sometimes you only need one deleted file — no need to recover the entire VM. PBS provides file restore, which reads a snapshot's contents and presents them as a browsable read-only filesystem, without writing back the entire VM disk. This is far faster than a full restore.

The most practical way is through the PBS web UI:

Datastore → select a backup group → select a snapshot.
Click File Restore.
The PBS server mounts the snapshot read-only and presents a file browser.
Check the files you need → Download.

PBS does this by skipping sparse blocks and reading only the relevant chunks — individual files can be fetched from a multi-GB disk in seconds.

#File Restore via CLI

For PXAR snapshots (host/file backups from episode 11), proxmox-backup-client provides direct mount:

Mount a PXAR archive read-only

proxmox-backup-client mount \
  --repository backup@pbs@10.0.1.10:store1 \
  host/web01/2026-08-12T22:15:01Z etc.pxar /mnt/pbs-restore

After mounting, you can cp the needed files then unmount:

Grab files then unmount

cp /mnt/pbs-restore/nginx/nginx.conf /etc/nginx/nginx.conf
proxmox-backup-client mount --repository backup@pbs@10.0.1.10:store1 --unmount /mnt/pbs-restore

Tip

VM file restore is also accessible from PVE: VM → Backup → select snapshot → File Restore. PVE borrows the PBS mechanism so you do not need to leave the interface you normally use. Practice this regularly — when a config file goes missing, this path is the fastest lifesaver.

#Real-World Recovery Cases

#Recovering Individual Files

A common scenario: nginx.conf gets corrupted after an update. From PBS file restore, you open last night's snapshot, download nginx.conf, and copy it back to the server. Total time: minutes, not hours — because no VM was fully restored.

#Boot Testing the Restore Result

A backup is only valuable if the restored result can boot. Make boot testing part of your routine procedure:

Restore the VM to a target storage with a different VM ID.
Start the restored VM.
Verify the primary services respond (e.g. curl to the VM IP, check logs).
Shut down and delete the test VM after success.

Warning

Never declare a backup strategy successful just because the GUI restore shows status OK. Boot test the restore result regularly — a VM that boots correctly is the only proof a backup is usable. This restore drill is also part of the production checklist in episode 22.

#Closing

Key takeaways:

A full restore rebuilds the entire VM/CT disk; it can target the same or a different PVE.
PBS snapshots are self-contained: complete metadata + data for cross-cluster recovery.
File restore reads a snapshot as a read-only filesystem without a full restore.
The proxmox-backup-client mount CLI for PXAR archives; the PBS/PVE GUI for VM file restore.
Recovering individual files is far faster than a full restore.
Always boot test the restore result — real proof that the backup works.

In the next episode, episode 6, we dive into the heart of PBS efficiency: deduplication & garbage collection — how content-defined chunking produces dedup across backups and VMs, how to read the datastore metrics, and the prune then garbage-collection flow to clean up unused chunks, plus their scheduling. Your storage will thank you!