A Proxmox VE backup is useful only when it protects the workloads you care about and can be restored within your recovery window. This guide explains how to choose a backup target, configure jobs, set retention, add an offsite copy and prove that recovery works.
What a Proxmox VE backup should protect
Start with the recovery outcome, not the storage product. List the virtual machines and containers that support each service, identify their owners, and decide how much data loss and downtime each service can tolerate. A backup plan should cover both guest data and the information needed to rebuild the Proxmox environment.
- Virtual machines and containers: include every guest needed to restore a service, including its configuration.
- Application-consistent data: databases and other stateful applications may need an in-guest dump, quiescing, or application-aware procedure in addition to a VM-level backup.
- Host and cluster configuration: keep a separate, protected record of network configuration, storage definitions, firewall rules, cluster details and recovery instructions. Do not assume guest backups recreate a lost cluster.
- Encryption keys and credentials: store them separately from the backups they unlock, with access limited to the recovery team.
For a broader recovery plan, see our guide to Proxmox disaster recovery and the overview of RPO and RTO.
Choose a backup method and target
Proxmox VE supports scheduled guest backups through vzdump. Jobs can write to file-based storage or to a Proxmox Backup Server (PBS) storage configured in the cluster. The right target depends on restore speed, capacity, network limits, retention needs and how much operational complexity your team can support.
| Approach | Useful when | Trade-off to plan for |
|---|---|---|
| File-based vzdump archives | You want a straightforward archive that can be copied to another system or removable media. | Plan capacity and transfer time; repeated full archives can consume substantial space. |
| Proxmox Backup Server | You need incremental transfers, deduplication, verification and integrated guest backup management. | It is an additional service to operate, secure, monitor and replicate offsite. |
| In-guest application backups | You need database-aware exports or file-level recovery for selected workloads. | They require workload-specific configuration and do not replace a complete guest recovery copy. |
These methods can complement one another. For example, a VM-level backup can restore the whole guest, while a database dump can provide a cleaner application-level recovery point. Compare the trade-offs in our article about Proxmox Backup Server and traditional backup tools.
Set a backup mode that matches the workload
Proxmox VE backup modes affect availability and consistency. In broad terms, snapshot mode aims to minimize guest downtime, suspend mode pauses the guest during parts of the operation, and stop mode shuts it down for the backup. Exact behavior depends on the guest, storage, guest agent and platform configuration, so validate the mode on representative systems before relying on it.
For databases and transactional services, a snapshot should not automatically be treated as an application-consistent backup. Install and configure the QEMU Guest Agent when appropriate, use the application's supported backup or quiescing mechanism, and keep a separate database-native recovery path when the recovery requirements call for it.
Create a scheduled backup job
In the Proxmox VE web interface, open Datacenter → Backup and create a job. Choose the target storage, node or selection of guests, schedule, mode, compression, notification behavior and retention policy. Start with a small set of non-critical guests, review the task log and confirm the resulting backup is visible on the target before expanding the job.
When configuring a job, pay attention to:
- Scope: explicitly include the guests that matter and decide how newly created guests will be added.
- Schedule: run backups often enough to meet the recovery point objective, while avoiding resource contention with peak workloads.
- Concurrency: limit simultaneous jobs if storage, CPU or network capacity is constrained.
- Notifications: send failures to an address or system someone monitors; a job that fails silently is not protection.
- Retention: keep enough recovery points for operational mistakes and longer-term requirements, and verify that pruning behaves as intended.
The Proxmox documentation explains the available backup and restore options and Proxmox Backup Server configuration.
Keep an offsite copy
A backup repository in the same server room can help after a guest disk failure, but it may be lost in a site outage, theft, fire or a compromise of shared administrator credentials. Keep at least one copy outside the primary failure domain. Depending on your design, this can be a remote PBS receiving sync jobs, a second site, or an object-storage destination with a tested transfer process.
Separate administrative access where possible. A compromised Proxmox administrator should not automatically have unrestricted permission to erase every historical and offsite copy. If you use immutability or object lock, test the retention and deletion behavior before production use. Our guide to backing up Proxmox VMs to the cloud discusses offsite options in more detail.
Use retention deliberately
Retention is a recovery decision as much as a storage setting. A short policy saves space but may leave no clean restore point after a problem is discovered late. A longer policy costs more and needs a plan for capacity growth. Define daily, weekly and monthly recovery points from actual business requirements, then estimate storage using guest size, change rate, compression, deduplication and the number of copies.
For PBS, configure prune and garbage-collection behavior with care: pruning removes recovery points according to the retention policy, while garbage collection reclaims chunks that are no longer referenced. Monitor datastore usage and confirm that the available space leaves room for normal growth and maintenance.
Verify backups and test restores
A successful task status proves that a job completed; it does not prove that the right data is recoverable or that the restore will meet your downtime target. Review job logs and verification results, alert on failures, and schedule restore exercises.
- Restore a file or directory from a representative guest.
- Restore a full VM or container to an isolated network or alternate storage.
- Check that the guest boots, its services start and application data passes integrity checks.
- Measure restore time and compare it with the recovery time objective.
- Practice recovery when the original node or primary backup target is unavailable.
Record who performs each step, what credentials and keys are required, and how to rebuild networking and storage mappings. Repeat the exercise after major changes to the cluster, backup target or application stack.
Common Proxmox VE backup mistakes
- Keeping the only backup on storage attached to the Proxmox host.
- Assuming high availability, snapshots or replication are substitutes for independent backups.
- Backing up a running database without checking application consistency requirements.
- Choosing retention without estimating growth or testing prune behavior.
- Ignoring failed jobs, verification warnings or datastore capacity alerts.
- Never testing a restore, or testing only on the same node and storage used for backup.
- Storing encryption keys, recovery credentials or runbooks only inside the environment they are meant to recover.
A practical Proxmox VE backup checklist
- Inventory guests and classify them by business criticality.
- Set recovery point and recovery time objectives for each service.
- Select a primary target such as file storage or Proxmox Backup Server.
- Create scheduled jobs, tune the mode per workload and enable failure notifications.
- Protect application data and host configuration with appropriate additional procedures.
- Set retention, capacity alerts and an offsite-copy strategy.
- Verify backups and document regular restore tests.
- Store recovery keys and instructions separately and review access permissions.
Backnix is developing its Proxmox backup integration; it is not currently presented as an available backup service. Follow the Proxmox backup feature page for its current status. Until the integration is released, use and test a backup solution that is available for your environment.