How to Back Up Proxmox: Recovery Planning and Restore Checks

To back up Proxmox VE, choose the guests and data you need to recover, send their backups to a separate destination, and test a restore. This documentation-based guide helps first-time administrators plan service recovery, not simply a completed task. Sources were reviewed on 19 October 2026.

Back up selected guests to separate storage or Proxmox Backup Server (PBS), schedule and retain recovery points, and monitor results. Guest protection covers selected workloads; rebuilding the host requires separate configuration records and recovery procedures. A successful backup job is an intermediate check, while successful application recovery is the outcome.

Key Takeaways

• Agree recovery priorities with service owners.
• Protect the data each service needs.
• Keep backups separate from the planned failure.
• Investigate failed and missed jobs.
• Test an isolated restore before relying on recovery.

How to back up Proxmox: start with the recovery goal

An application VM can start while its unavailable database leaves the service unusable. Your recovery goal must describe a working service, not merely a running guest.

Recovery point objective (RPO) is the maximum amount of recent data you can afford to lose, expressed as time. Recovery time objective (RTO) is the target time to restore an agreed service to use. Measure recovery through application acceptance, not just disk restoration or guest boot.

Ask service owners to agree acceptable data loss, restoration time and application acceptance checks. Those checks might require signing in, retrieving an existing record and completing a new transaction. Record who can approve the recovered service and who can resolve a failed check.

For a database-backed application, identity services may enable sign-in, DNS may locate the database, and the database must become usable before the application can serve requests. These recovery dependencies determine restoration order, even when the application guest itself restores first.

Separate guest loss, host loss, storage loss and site loss. Each removes different resources needed for recovery. Backup frequency alone does not establish an achieved RPO: failed jobs and unusable recovery points can leave an older recoverable state than the schedule suggests.

Turn the agreed failure scenarios and recovery priorities into requirements for a backup destination, including where it must remain accessible.

Choose a backup destination and method

Conventional backups create full archive files; Proxmox Backup Server (PBS) stores recovery points in a deduplicated datastore. Proxmox VE integrates guest backup and restore through its web interface and the vzdump tool.

File-based backups are full backup archives containing guest configuration and included data, not backups limited to individual files. An NFS share is one possible file-backed destination; a PBS datastore is another approach. The Proxmox backup location must survive the failure you are planning for. A separate directory on the production disk does not survive that disk failing.

PBS uses incremental transfer and reuses existing chunks rather than transferring every byte on every run. Each recovery point still represents a complete logical backup, although its data can share chunks with other recovery points. The Proxmox Backup Server overview describes client-side encryption and data-integrity checking alongside its deduplicated storage.

Proxmox Backup Server setup involves preparing the server and datastore, verifying connectivity and certificate identity, adding the PBS destination to Proxmox VE, and assigning narrowly scoped credentials. Distinguish permission to write backups from permission to restore or delete them. Do not give routine backup credentials unrestricted deletion rights merely for convenience.

Use the Proxmox VE Administration Guide for installation and storage integration procedures matching your installed version. The PBS features reference provides context for permissions, encryption and integrity checks.

Keep encryption keys and recovery credentials accessible outside the failed host, under protected custody. Test that an authorised administrator can retrieve and use them during recovery without relying on services that may also be unavailable.

Confirm that the destination is usable before deciding exactly which guest data it will protect.

Record what the backup includes and excludes

A protected container can still lose its application data if that data sits on an unprotected bind mount. Selecting the container does not mean every mounted dataset becomes backup data.

Proxmox VE manages KVM virtual machines and LXC containers. Guest backups include guest configuration and selected data, not an automatic bare-metal backup of the host. Create a guest inventory that records both inclusion and exclusion decisions.

• Guest identifiers and service owners: record each guest’s role, owner and recovery priority.
• Required VM disks and backup flags: check each disk, including excluded disks that still hold necessary data.
• Container root filesystems and mount-point treatment: record mount types, backup settings and separately protected datasets.
• Externally stored application data and dependencies: identify remote databases, file shares and services needed during recovery.
• Host-rebuild records and credentials: preserve configuration details, access requirements and the procedure for restoring administrative control.

VM disks can be excluded from backup. Container mount-point inclusion depends on mount type and backup settings; bind mounts and device mounts are not included as ordinary container backup data. Give any required excluded dataset its own protection method.

Deciding how to back up the Proxmox server itself is a separate host-rebuild and configuration-protection task. To establish how to back up Proxmox configuration, inventory /etc/pve, networking, storage definitions, installed versions and required secrets. Protect host configuration records because they can expose credentials and infrastructure details.

Treat host and cluster recovery as documented procedures. A configuration copy alone is not a complete recovery plan, and restoring configuration should not mean indiscriminately overwriting a running host.

Use the completed inclusion and exclusion record to configure the first backup job.

Plan the backup job, retention and off-site copy

Your backup job must reflect the inventory and recovery objective, rather than inherit unchecked defaults. Proxmox VE supports manual guest backups and scheduled jobs covering selected nodes and guests.

Connect the backup schedule to the agreed RPO and observed runtime. A job that starts regularly but cannot finish reliably does not deliver the recovery history you intended.

1. Select the destination and intended guests, checking that the selected nodes can reach the destination.
2. Verify included disks and mount points against your inclusion and exclusion record.
3. Choose the backup mode and applicable compression settings for your destination and guest type.
4. Run a manual backup from the guest backup controls and inspect its completion log.
5. Configure the scheduled job with explicit guest-selection behaviour and timezone, including treatment of newly created guests.
6. Set backup retention and a separately managed off-site copy that addresses the agreed failure scenarios.

Choose the mode using the documentation for the exact VM or container type. Interruption and consistency trade-offs differ; databases may also need application-native protection. Do not assume every backup taken while a guest runs is application-consistent. A snapshot-mode backup creates backup data; it is different from merely retaining a storage snapshot.

Filesystem quiescing and application-native protection may be needed for recoverable databases. Check exact behaviour against documentation for your installed version. For version-specific further reading, consult the Proxmox VE Administration Guide 9.2.

For Singapore operations, verify the configured timezone rather than assuming it is Asia/Singapore. Check whether newly created guests are automatically included or omitted; either behaviour must be a deliberate policy choice.

Retention must preserve enough recovery history for operational and organisational requirements. The PBS maintenance documentation distinguishes pruning, which removes recovery-point metadata, from garbage collection, which reclaims eligible unreferenced chunks. PBS supports remote backup arrangements and synchronisation, but an off-site copy sharing unrestricted deletion credentials can share a damaging failure.

Move from a configured job to evidence that jobs run, recovery points remain usable and applications can return.

Check backup results and rehearse a restore

Recovery-point age and restore results reveal more than a green task status. Proxmox VE task history and logs show backup operations; an isolated restore rehearsal tests whether you can actually recover a service.

PBS verification checks backup-data integrity, not application-level recoverability. Your backup monitoring must detect failed or missed jobs, ageing recovery points, destination capacity problems, PBS verification failures and stale secondary copies. Assign a named alert owner and test the notification route.

The Proxmox VE features overview describes integrated backup and restore capabilities. Use those controls to perform a rehearsal away from production, with the service owner available to judge the result.

1. Choose a recovery point and confirm that recovery credentials and any encryption keys are accessible.
2. Restore with an unused guest identity onto an isolated network, without replacing the production guest.
3. Check required disks and application transactions with the service owner, including whether the recovered data is recent enough.
4. Record results and measured recovery time before safe cleanup; retain defects and assign corrective work.

Isolation must prevent duplicate addresses, scheduled integrations and outbound messages from reaching production. A different guest identifier alone does not provide that separation. Check the restored guest’s network access before allowing applications or scheduled tasks to run.

These recovery checks remain necessary with snapshots, replication or HA because workload availability does not establish that retained data is correct or that the application can use it.

Backup, snapshots, replication and HA compared

High availability can bring a service online without restoring yesterday’s correct data. Backup supplies retained recovery points; a storage snapshot, storage replication and HA address different recovery or availability needs.

An available but corrupted replicated service is not a recovered service. Replication can carry unwanted changes to the secondary copy, leaving both copies unsuitable for the application’s acceptance checks.

A storage snapshot here is distinct from snapshot-mode backup. The former normally depends on its underlying storage; the latter is a method of creating a backup. HA can restart workloads after supported failures, but it does not choose an earlier, correct application state.

Backup questions and your next learning step

Does a successful backup job prove that the application will recover?

No. Job completion is one check. Restore the required data in isolation, then have the service owner verify that the application works and that the recovered information is recent enough.

Does selecting a container protect every mounted dataset?

No. Review its mount points and backup settings. The Proxmox VE manual explains that bind and device mount contents are not included in vzdump backups; protect required excluded data separately.

Does HA replace retained backups?

No. Availability and historical recovery address different needs. Keep usable recovery points even when workloads can restart on another host.

Choose one important service and record the next rehearsal, its administrator and the person who will approve the recovered application. For configuration confidence, explore the Proxmox VE administrator training. For unresolved objectives or dependencies, take the next step with Proxmox Discovery.