A backup strategy starts with the failure you want to survive. A second directory on the same disk helps little when that disk fails. An off-site copy is useful only if its credentials, metadata, and encryption keys are available during recovery.
This article helps you choose copies and recovery goals. For installation and datastore configuration, use the PBS setup and first restore guide.
Verification status
| Area | Evidence and limits |
|---|---|
| Technical review | Reviewed against the official documentation linked below on October 31, 2026. |
| Policies | Schedules and retention counts are planning examples, not measured results. |
| Runtime | No backup, sync, disk formatting, or guest restore was executed for this revision. |
| Required evidence | Test a restore from each copy you intend to depend on, including saved encryption keys. |
1. Set two recovery targets
Recovery point objective (RPO) is how much recent work you can lose. Recovery time objective (RTO) is how long the service can remain unavailable.
Write these down per service before choosing schedules:
| Service | Example RPO | Example RTO | Recovery dependency |
|---|---|---|---|
| Lab application | 24 hours | One day | Guest backup and application secrets |
| Important documents | Four hours | Four hours | Data backup, permissions, and encryption key |
| DNS or identity service | Set from your outage tolerance | Set from your outage tolerance | Network access and offline recovery credentials |
These are proposed targets. Time a real restore to see whether your hardware and network meet them. Application data may need database-native backups in addition to guest backups.
2. Count copies and failure boundaries
Use the 3-2-1 rule as a planning baseline: three copies including the working data, two media types, and one copy off-site. Also inspect shared hosts, power, storage controllers, and administrator credentials.
| Copy | Example location | What to check |
|---|---|---|
| Working data | PVE guest disks | This is the source, not an extra backup. |
| Local backup | PBS on separate hardware and storage | Can it survive loss of the PVE host? |
| Off-site backup | Second PBS at another site | Can you restore if the first site and its credentials are unavailable? |
Two datastores are not automatically two independent copies. Creating a second empty datastore does not duplicate the first. A PBS VM on its protected PVE host can support a lab exercise, but shares that host’s failure risks.
An offline removable copy can reduce exposure to compromised online credentials. Plan secure storage, rotation, and a recovery test for it.
3. Choose archive storage or PBS
PVE’s backup tooling can target file storage or PBS. PBS integration is a storage choice within PVE’s backup workflow.
| Destination | Useful when | Planning tradeoff |
|---|---|---|
| File storage such as an NFS backup target | You want conventional backup archives | Budget space and transfer time for full archives. |
| PBS datastore | You want deduplication, incremental transfer, and scheduled integrity checks | Operate PBS, its maintenance jobs, and recovery credentials. |
A PBS snapshot is a complete restore point even when only changed chunks transfer. Measure savings with your own guests; there is no fixed deduplication ratio.
Use the PVE backup documentation for backup modes. VM and container stop, suspend, and snapshot modes behave differently. Live backup and guest-agent filesystem freezing do not by themselves prove database consistency. Check which disks and container mount points are included.
In PVE Datacenter → Backup, first create a job for one disposable guest and an explicit target storage. Run it manually and inspect the log. Then choose a calendar schedule using the interface’s schedule selector and preview. Do not paste a Unix cron expression into a field expecting Proxmox calendar syntax.
4. Keep retention separate from cleanup
An example starting policy is 7 daily, 4 weekly, and 3 monthly restore points. Adjust it for change rate, recovery needs, and measured capacity.
Configure retention in the appropriate PVE backup job or PBS prune job. Avoid conflicting policies that remove restore points another policy was meant to keep.
For PBS, pruning removes snapshot metadata; garbage collection later reclaims eligible unreferenced chunks after its grace period. Verification checks integrity. These are separate tasks, and none replaces booting a restored guest. See PBS maintenance.
Keep capacity headroom and review job failures. A nightly schedule is only a plan until task results show successful backups.
5. Make the off-site copy recoverable
For a second PBS, use a supported sync job. A straightforward design is a pull job on the destination PBS:
- Register the source PBS as a remote on the destination, verifying its TLS identity.
- Select the source datastore and destination datastore, with appropriate access permissions.
- Run the job manually on a small test backup and inspect the destination contents.
- Decide the destination’s own retention policy. Leave removal of vanished source snapshots disabled initially so source deletion is not automatically mirrored.
- Restore from the destination before enabling its regular schedule.
Follow PBS remotes and sync for your installed version. Restrict source access to the permissions required by the sync job. Keep destination administration credentials separate from the PVE backup account.
Copying only .chunks/ omits the metadata needed to identify and restore snapshots. Treat ad hoc copying of a changing datastore as an unproven recovery method. Prefer a documented PBS workflow, and test the resulting copy.
For removable storage, use the installed release’s datastore management guidance. Identify the device before creating a filesystem, verify its mount state, and complete tasks before unmounting. This strategy guide intentionally provides no disk-formatting command.
6. Test recovery without touching the original
Select a known snapshot in PVE’s backup list and restore it to an unused guest ID with automatic startup disabled. Before booting, disconnect its network interfaces or attach them to an isolated test network.
Check the expected files and applications. Record the source snapshot, destination storage, installed versions, elapsed time, and result. Include a restore from the off-site copy and, if encrypted, recovery using the separately saved key.
Only remove the disposable restored guest after confirming its identity. Automate this exercise after a manual run works and the automation explicitly checks target IDs, isolation, failure handling, and cleanup. A boot or guest-agent response alone does not verify application data.
7. Keep a recovery worksheet outside the cluster
Record:
- How to reach backup storage when normal DNS, identity, or VPN services are down.
- PBS configuration recovery, storage attachment, and account recreation steps.
- Encryption-key locations and required recovery secrets.
- Guest restore order based on dependencies.
- The last successful backup, off-site sync, and restore-test dates.
For a host loss, recover access to the backup copy first, prepare replacement PVE capacity, and restore services in dependency order. For site loss, repeat the exercise using only the off-site materials. Update RTO estimates from the time this actually takes.
Continue reading
- PBS setup and first restore — Configure the backup service.
- Intel AMT Serial over LAN — Prepare another route to a host console.
- Proxmox bridges and VLANs — Document the network needed during recovery.
Application backups alongside guest backups
For PostgreSQL application data, follow the atomic dump, scheduler, and Restic-to-database recovery lab. For ordinary prepared files, use the Restic file recovery guide. Their disposable Docker results do not validate a PBS sync, VM restore, or production application; keep those recovery tests distinct.