Proxmox snapshots are not backups
Proxmox gives you a few different ways to protect VMs and containers, and they do different jobs. A snapshot captures the state of a VM at a point in time. It is useful for quick rollback after a change goes wrong. It is not a full backup.
Snapshot jobs can be started from the GUI or with scripts. The built-in backup job feature can be used to schedule them, and custom scripts can be run from cron if you want tighter control over timing or retention. Just do not mistake that for backup discipline. A snapshot that lives on the same storage as the VM is still sitting on the same failure domain.
Snapshots also eat space. If you leave them lying around, storage use climbs fast enough.
ZFS snapshots
ZFS snapshots are useful inside a Proxmox setup because they capture the state of a filesystem at a point in time. With copy-on-write, they are lightweight at first and only grow as data changes after the snapshot is taken.
That makes them handy for frequent point-in-time recovery, but they still need pruning. If you do not keep an eye on retention, they pile up and the storage starts getting tight. Rollback is only useful if the pool has room left to breathe.
Rsync replication and Proxmox replication
Rsync and Proxmox replication are not the same thing. Rsync synchronises files between systems and only transfers the differences. That makes it a decent fit for file-based backups.
Proxmox replication copies whole VM state to another system. That is better when you want a VM ready to bring up or move across quickly. Which one makes sense depends on what you are trying to protect.
Scheduling and retention
A sensible backup schedule starts with the systems that matter most. More important VMs need shorter gaps between backups. Less important ones can usually sit on a slower schedule.
Incremental backups can reduce storage use and cut backup time because they only copy changes since the last run.
Proxmox Backup Server also has a prune simulator, which is useful when you are checking retention rules before they bite you in production.
Automation matters as well. Scripts and cron jobs remove the chance of somebody forgetting to run the job by hand.
Pruning snapshots
Snapshot pruning is part of the job. Old snapshots use space and, if left alone, can fill a datastore at the worst possible moment.
Proxmox can keep a fixed number of snapshots through retention settings. That keeps the mess under control and avoids a pile of stale restore points nobody will ever use.
If pruning is ignored, the usual outcome is a full storage pool, failed backups, and a bad afternoon.
What needs checking in Proxmox VE 9.0
The original article mentions Proxmox VE 9.0 as having better snapshot management, but that claim needs checking before it is relied on. The safer point is simple: check what your version actually supports before you build a backup routine around it.
Practical steps
- Assess your VMs: work out which ones need frequent backups and which ones can wait.
- Pick the right method: use Proxmox replication or Rsync based on what you need to recover.
- Set the schedule: use the GUI or scripts to automate it.
- Use ZFS snapshots carefully: they are useful, but they still need retention management.
- Prune old snapshots: keep the list short enough to manage.
- Test restores: a backup you have not restored is just hope with a timestamp.
