Proxmox Backup Server as a restore foundation

Proxmox Backup Server should not be deployed only to check a backup box. The useful use case is more concrete: protect a small Proxmox VE cluster, quickly restore a VM after an operational mistake, return to a known state after a failed application update, and keep a recovery point if local storage becomes unavailable. In that context, installing PBS is only the first step. The real subject is restore capability.

The scenario here is a three-node Proxmox VE cluster with around fifteen virtual machines. Some VMs are critical, such as a file server, a monitoring tool, an internal application server, or a test domain controller. Others can be rebuilt with Ansible or Terraform. PBS is installed on a separate machine, with a dedicated datastore, an identified backup network, and a Proxmox VE account limited to backup operations.

Define backup classes

The first action is to classify VMs. A single policy applied to the whole cluster is simple, but it does not match real requirements. A critical VM needs a different frequency and retention than a temporary VM. A rebuildable VM does not always deserve the same storage cost as a server containing state.

Critical class
Examples: files, monitoring, directory, internal application
Daily or more frequent backup
Longer retention
Planned restore test

Standard class
Examples: internal tools, secondary application servers
Daily backup
Intermediate retention
Sample-based restore test

Rebuildable class
Examples: workers, test VMs, IaC-generated machines
Short retention
Optional backup
Documented rebuild path

This classification must be written before creating jobs. Otherwise, retention becomes a technical choice in the interface instead of an operations decision. Storage then compensates for the absence of prioritization.

Create a datastore that can be operated

The PBS datastore must be sized with retention and VM change rate in mind. Deduplication helps a lot, but it does not replace capacity tracking. A datastore that looks comfortable at the beginning can become fragile after a few months if new VMs are added or retention is extended.

The minimum is to track available space, backup duration, verification errors, and garbage collection duration. If PBS runs on storage that is too slow, backups may complete but restores become painful. A restore test is therefore also a performance test for the datastore.

proxmox-backup-manager datastore list
proxmox-backup-manager garbage-collection status <datastore>
proxmox-backup-manager verify-job list
df -h
lsblk
journalctl -u proxmox-backup-proxy -n 100 --no-pager

The datastore must not be treated as a forgotten disk. Available space should alert someone. Verification errors must be read. An unusually long garbage collection task should raise questions about storage, execution windows, or backup growth.

Connect Proxmox VE with a limited account

Proxmox VE should write to PBS with an appropriate account. Using a general administrator account for backups makes configuration easier, but increases risk. A dedicated datastore account, with the required permissions and nothing more, creates a cleaner model.

In Proxmox VE, the PBS storage entry must include the datastore, fingerprint, account, namespace if used, and encryption options if the policy requires them. Client-side encryption is useful, but it imposes discipline around key retention. An encrypted backup whose key is unavailable is unusable.

Dedicated PBS account
Used by Proxmox VE for backup operations
Permissions limited to the expected datastore or namespace
No shared human account

Encryption keys
Stored outside the Proxmox VE cluster
Backed up in a controlled vault
Tested during a real restore

This is an operational point. A team must know where the keys are, who can use them, and how to restore if the original Proxmox VE cluster is no longer available.

Schedule jobs by criticality

Backup jobs should follow the classes already defined. Critical VMs can use a daily backup with longer retention. Standard VMs can follow a simpler policy. Rebuildable VMs can be excluded or backed up with short retention.

Job critical-daily
Targets: critical VMs
Frequency: daily
Retention: 14 daily, 8 weekly, 6 monthly
Verification: regular

Job standard-daily
Targets: standard VMs
Frequency: daily
Retention: 7 daily, 4 weekly
Verification: sample-based

Job rebuildable-short
Targets: rebuildable VMs
Frequency: as needed
Retention: short
Alternative: automated rebuild

Retention must be understandable by the team. If nobody can explain why 14 daily and 6 monthly restore points are kept, the policy is not governed. It is merely configured.

Understand pruning and garbage collection

PBS separates pruning and garbage collection. Pruning applies the retention policy by removing references. Garbage collection then reclaims blocks that are no longer referenced. This often surprises teams during early cleanups, because disk space is not always freed immediately after a retention change.

PBS cycle
Backup writes new chunks
Prune removes references outside retention
Garbage collection reclaims unreferenced chunks
Verify checks backup readability
Restore test proves that backup is usable

Pruning, garbage collection, and verification must therefore be scheduled in windows that match activity. Running all heavy operations at the same time can degrade performance, especially on a small PBS server.

Test a full restore

The most important test is a full VM restore into an isolated environment. The incident is not the right moment to discover that restore is slow, that the restored network is not appropriate, that the IP address conflicts, or that the VM depends on an external service that is absent.

Recommended monthly test
Select a standard VM
Restore with a different name
Boot in an isolated network
Check boot, disk, network, and main service
Measure restore time
Remove the test VM after validation

For a critical VM, the test should also include minimum dependencies. An application server can boot but remain unusable if the database, DNS, application secret, or required route is missing. The test must therefore validate the delivered service, not only the boot sequence.

Prepare for cluster loss

A local restore test is not enough. The most important scenario is sometimes the loss of the original Proxmox VE cluster. In that case, the team must know how to access PBS, retrieve keys, add PBS storage to a new cluster or emergency host, and restore priority VMs.

Loss of the Proxmox VE cluster
1. Access the PBS interface
2. Check datastore state
3. Retrieve encryption keys if required
4. Install or use an emergency Proxmox VE host
5. Add PBS storage
6. Restore critical VMs first
7. Validate services before secondary VMs

This procedure must be tested at least partially. Without that, PBS protects against day-to-day mistakes, but not necessarily against a wider loss.

Conclusion

Proxmox Backup Server becomes a real restore foundation when it is tied to backup classes, explained retention, a monitored datastore, limited accounts, correctly stored keys, and actual restore tests. Success is not measured by the number of green backup jobs, but by the ability to restore a useful VM within a known delay.

A good minimum for a small platform is simple: three VM classes, two or three backup jobs, regular verification, scheduled garbage collection, a monthly restore test, and a cluster-loss runbook. With that, PBS stops being a backup repository and becomes an operable recovery tool.