A backup job is a mechanism. A backup strategy is an answer to a set of failures: accidental deletion, a broken upgrade, a dead boot device, loss of a Proxmox node, corruption of the backup store, and loss of the room containing both systems. One copy on a large disk addresses only some of them.
The useful starting point is not a product. It is the recovery objective for each workload.
Classify what must return #
List every VM and container with an owner, data location, and dependency. Then choose a recovery point objective (how much recent data can be lost) and a recovery time objective (how long the service can remain unavailable).
A DNS resolver rebuilt from configuration may tolerate a day-old backup and a short outage. A family document store may need several restore points per day and careful off-site protection. A media cache may not need a backup at all if the source is reproducible.
This classification prevents two common mistakes: protecting disposable data forever and treating irreplaceable data like another test VM.
Configuration may need a different path from bulk data. A VM backup can restore the whole appliance quickly, while a small encrypted repository containing Ansible, compose files, and network documentation makes individual settings easy to inspect. Application-native exports are valuable for databases because they offer another recovery route and can be validated without starting the original guest. These layers complement rather than replace one another.
Separate failure domains #
Proxmox Backup Server integrates well with Proxmox VE, supports incremental deduplicated backups, verification, retention policies, and remote synchronization. It can be an excellent local backup target. It is not magically separate when it runs as a guest on the same storage it protects.
A stronger local design uses independent storage and, ideally, a separate machine. That protects against failure of the main host and makes restores possible while the compute node is being rebuilt. The backup server still shares risks such as theft, fire, power damage, and administrative mistakes, so add another copy in a different failure domain.
The familiar 3-2-1 guideline—three copies, two kinds of storage, one off-site—is a useful review prompt rather than a mathematical guarantee. Ask which event can remove each copy simultaneously. Two datasets on the same ZFS pool are not two meaningful failure domains.
Schedule around change rate #
Match backup frequency to the amount of acceptable loss. A nightly job is reasonable for a slowly changing utility. A database receiving important changes throughout the day needs more frequent protection or an application backup in addition to VM snapshots.
Stagger jobs so that every guest does not create load at the same minute. Leave time for pruning, garbage collection, verification, and off-site synchronization. A schedule that completes only on quiet days is already too dense.
In Proxmox VE, inspect the configured jobs rather than relying on memory:
1pvesh get /cluster/backup
The output should match the written inventory: correct storage, guest selection, schedule, mode, and retention. Avoid broad exclusions that can silently omit a new important guest.
Treat retention as several windows #
Keeping the latest 30 backups is easy to understand but often wasteful. It gives many recent points and then an abrupt cliff. Calendar-based retention preserves dense recent history and sparse older history. A starting policy might keep:
- the last four successful snapshots;
- seven daily snapshots;
- five weekly snapshots;
- twelve monthly snapshots;
- two yearly snapshots for truly durable data.
These are examples, not universal values. Model the result with the Proxmox Backup Server prune simulator before applying it. Retention options interact, and the retained set depends on the actual backup timestamps.
Pruning removes snapshot references according to policy. Garbage collection later reclaims chunks that are no longer referenced. Schedule both and monitor their results. A datastore that is never pruned eventually fills; one that is pruned without the intended policy can remove the recovery point you expected.
Verify data and notifications #
Proxmox Backup Server stores checksums and supports verification jobs. Run them regularly enough to discover unreadable data before the last good copy ages out. Verification adds evidence that stored chunks match their recorded checksums, but it does not prove the restored application will work.
Also make failures visible. A job log that nobody reads is not monitoring. Configure notifications for failed backup, sync, prune, garbage-collection, and verification tasks, then generate a harmless test notification or controlled failure to confirm delivery.
For a quick operational view on the backup server, inspect recent tasks and datastore status through the supported interface or CLI rather than parsing internal files. The exact commands can evolve, so keep the runbook linked to the documentation used for the installed release.
Protect credentials and keys #
Backups can contain nearly every secret in the environment. Limit access to the backup server, use dedicated accounts or tokens with the minimum required privileges, and separate backup permission from pruning permission when the platform supports it. A compromised client should not automatically be able to delete its historical recovery points.
If client-side encryption is enabled, store the recovery key outside the systems being backed up. Print it or place it in a managed secret store with a tested retrieval procedure. Encryption without recoverable keys converts a hardware failure into permanent data loss.
Add an off-site copy #
An off-site target can be another Proxmox Backup Server, removable media stored elsewhere, or a different backup system. The transport matters less than the independence and the restore path.
Consider bandwidth, initial synchronization time, retention at the destination, and whether deletion at the source propagates immediately. A permanently connected remote with identical credentials may reproduce an operator mistake very efficiently. Delayed sync, restricted permissions, or offline media can create valuable resistance.
Do not call the copy off-site if it is a USB disk sitting on top of the server. It is separate storage but the same physical failure domain.
Restore in layers #
Test three different recovery levels:
- Restore an individual file from a guest backup.
- Restore a complete VM or container into an isolated network.
- Rebuild enough of the backup and compute environment to restore when the original Proxmox node is unavailable.
The third test exposes dependencies hidden by routine restores: network configuration, storage credentials, encryption keys, installation media, and the instructions for adding the backup datastore to a clean host.
Use an isolated bridge for the restored guest until identity conflicts are resolved. Starting a duplicate domain controller, DHCP server, or database on the live network can turn a restore test into an outage. Change the temporary guest's address only when the application supports it; otherwise isolate the network and place the test client beside it.
During a full guest test, check more than boot completion. Confirm application data, authentication, scheduled jobs, mounted storage, and dependent services. Measure the duration and compare it with the recovery objective.
Keep a small recovery packet #
Store a concise, offline-accessible recovery packet containing:
- the network and storage layout;
- backup server address and datastore names;
- where credentials and encryption keys can be retrieved;
- the order in which infrastructure services must return;
- the last restore-test date and result;
- contact and hardware warranty information, if relevant.
Do not put raw secrets in an ordinary document. Point to their protected location and explain how an authorized operator retrieves them.
Review the strategy after change #
New storage, a renamed guest, a second node, or a service moved into Docker can invalidate old assumptions. Add backup review to the completion checklist for every infrastructure change. The question is not only “Did tonight's job run?” but “Can the environment still be reconstructed from what is protected?”
A resilient strategy has multiple copies, observable jobs, deliberate retention, recoverable keys, and recent restore evidence. The product performs the backups. The strategy makes them useful on the worst day of the homelab.
Review capacity as well as job status. Deduplication can hide growth for a long time and then change quickly when a workload begins storing compressed or encrypted data. Alert before the datastore becomes full, leave working space for maintenance, and record the expected growth assumptions. Capacity planning is part of recovery planning because a full target stops creating new recovery points precisely when old ones may already be aging out.