A manual backup is fine until the day you forget to run one. Proxmox solves that with scheduled backup jobs — you define what to back up, where, and on what calendar, and the host runs vzdump for you on time, every time. The job lives at the Datacenter level, so it covers whichever node a VM happens to be running on.
This guide is about the scheduling itself: building a backup job in the GUI, writing the calendar expression that controls when it fires, choosing a selection mode that quietly picks up new VMs, setting retention so the storage doesn’t fill, and wiring up notifications so a failed job doesn’t go unnoticed. If you need the mechanics of the backup modes and how to restore, the back up and restore guide covers that ground; here the focus is automation.
Steps target Proxmox VE 8.x. The job builder and the notification system both changed in 8.x, so older screenshots you find elsewhere may not match.
Create the backup job
Scheduled backups are configured under Datacenter → Backup, not on an individual node. That placement matters: a Datacenter job follows your VMs around the cluster, so a machine that lives on node1 today and migrates to node2 tomorrow keeps getting backed up by the same job.
Click Add and you’ll set:
Backup job fields
| Storage | The backup target — an NFS/CIFS share, a local directory, or a Proxmox Backup Server datastore. |
|---|---|
| Schedule | When the job runs, as a calendar expression (covered below). |
| Selection mode | All VMs, a specific list, all-except a list, or a pool. |
| Mode | snapshot, suspend, or stop — how the disk is captured. |
| Compression | zstd (the sensible default), LZO, or GZIP. |
| Retention | Prune rules so old backups are deleted automatically. |
Set the storage and the schedule, pick a selection mode, leave compression on zstd unless you have a reason to change it, and move on to retention. The job saves as an entry in /etc/pve/jobs.cfg and runs on the schedule from then on.
Write the schedule
Proxmox uses systemd calendar event syntax for the schedule. The GUI has a basic builder with day and time pickers, but you can type an expression directly in the Schedule field for anything it can’t express.
The common patterns:
02:30 # every day at 02:30
mon..fri 21:00 # weekdays at 21:00
sat 04:00 # Saturdays at 04:00
sun 03:00 # Sundays at 03:00
*/6:00 # every 6 hours, on the hour (00:00, 06:00, ...)
mon,wed,fri 23:00 # Mon/Wed/Fri at 23:00
*-*-1 05:00 # the 1st of every month at 05:00A few things worth knowing. Day ranges use .. (mon..fri), lists use commas (mon,wed,fri), and */6:00 means “every six hours” rather than a fixed time. Times are in the host’s timezone. If you want to confirm an expression does what you think, systemd-analyze will show you the next few run times:
# preview when an expression will next fire
systemd-analyze calendar 'mon..fri 21:00'Choose a selection mode that scales
The selection mode decides which VMs the job covers, and the choice has a long-term consequence most people don’t think about: whether new VMs are protected automatically.
Backup job selection modes
| All | Every VM and container in the cluster. New machines are included automatically. |
|---|---|
| Exclude | Everything except a named list. New machines are included automatically. |
| Pool based | Every guest in a resource pool. New machines are covered once added to the pool. |
| Include (specific IDs) | Only the VMIDs you list. New machines are NOT backed up until you edit the job. |
For most environments, All or Exclude is the safer default. A freshly built VM is exactly the kind of thing that gets forgotten, and an open-ended selection mode means it’s protected from its first night. If you need fine control, Pool based is a good middle ground — add a VM to the pool and it inherits the backup automatically.
The trap is Include with a fixed list of VMIDs. It works, but every new VM is silently unprotected until someone remembers to add it. If you use it, make adding the VM to the job part of your build process.
Set retention so the target doesn’t fill
A schedule without retention is a slow-motion outage: every run adds a file, the storage fills, and then backups start failing — usually right before you need one. Proxmox prunes automatically using keep rules set on the job’s Retention tab.
The keep options stack, so you hold many recent backups and progressively fewer older ones:
keep-last=3 # the 3 most recent, always
keep-daily=7 # one per day for 7 days
keep-weekly=4 # one per week for 4 weeks
keep-monthly=6 # one per month for 6 monthsThat set keeps roughly six months of history while storing only a couple of dozen files per VM. Proxmox runs the prune after each successful backup, so the target stays bounded.
Get told when a job fails
A scheduled backup that fails quietly is worse than no backup, because you think you’re covered. Proxmox VE 8.x has a notification system under Datacenter → Notifications where you set up a target and decide when it fires.
The flow is: add a notification target (an SMTP email target, or a gateway), then a matcher that routes events to it. On the backup job itself, the Notification mode can be set to notify always or only on failure.
At a minimum, set jobs to notify on failure. A daily “backup succeeded” email is easy to start ignoring; a message that only arrives when something broke is the one you’ll actually read. Once configured, send a test notification from the target so you know the email path works before you rely on it.
A schedule that actually protects you
Putting the pieces together, a scheduled setup that holds up looks like this:
Scheduled backup checklist
- Job created at Datacenter level, not on a single node
- Selection mode is All or Exclude so new VMs are covered automatically
- Schedule runs in an off-hours window, staggered if you have several jobs
- Backups land on storage separate from the host (NFS, CIFS, or PBS)
- Retention rules set so old backups prune automatically
- Notifications configured to alert on failure, and tested
- A restore tested to a spare VMID in the last month
If you run several jobs, stagger their start times. vzdump processes a node’s VMs sequentially within a job, but two jobs hitting the same NFS share at 02:00 compete for the same bandwidth and the window stretches. Spread heavy VMs across different times or split them into separate jobs with their own schedules.
For larger fleets, the backup target is what makes daily schedules practical. A Proxmox Backup Server only ships changed blocks, so a nightly backup of a big VM takes minutes instead of rewriting the whole disk — which keeps the schedule from running into the morning.
Wrapping up
Automating Proxmox backups comes down to four decisions: where the files go, when the job runs, which VMs it covers, and how long backups are kept. Create the job at the Datacenter level, use an open-ended selection mode so new VMs aren’t forgotten, set retention so the storage stays bounded, and turn on failure notifications so a broken job surfaces fast. Then prove it with one manual run and one test restore.
For the underlying backup mechanics and the restore side, see back up and restore Proxmox VMs. For more walkthroughs, browse the Proxmox guides.
