Scheduled Snapshots
Create snapshots automatically on a cron schedule, with retention policies.
AutoSnap
Automated snapshot scheduling and management for Proxmox VE virtual machines and containers.
Features
Section titled “Features”Retention Policies
Define how many snapshots to keep per VM, with automatic cleanup of expired ones.
Configure snapshot jobs with cron schedule, VM selection, execution history and status monitoring.
Multi-VM Support
Apply a single job to multiple VMs and containers using filters or explicit selection.
Node-independent
A job targets VM IDs, ranges, name wildcards, pools or tags, with optional exclusions. It is not tied to a node unless you use @node-…. When a VM migrates (manually or by HA failover), the next scheduled snapshot runs on the new node with no reconfiguration.
Trigger HTTP webhooks on snapshot phase events (before/after create, before/after delete). Configure per-job HTTP endpoints with custom headers and body templates.
Proxmox can already take snapshots: why use a module for it?
Snapshots actually happen
Snapshots run on a schedule you choose. Nobody has to remember to take one before the next risky operation.
Manage 50 VMs as one set
One job targets a group of VMs by tags, wildcards or an explicit list. You do not repeat the configuration for each VM.
Different schedules per workload
Hourly for the database, nightly for dev VMs, weekly for templates: each job runs on its own cron, side by side on the same cluster.
Follows the VM, not the node
A job targets VM IDs, pools or tags, not a node (unless you use @node-…). When a VM migrates to another node, the next snapshot runs there with no reconfiguration.
Retention without thinking
Set Retention to 7 once; when the 8th snapshot is created, the module deletes the oldest one for you. Proxmox VE alone keeps every snapshot until someone deletes it.
Storage-safe by default
Max percentage storage skips the snapshot when the target storage is too full, so scheduled snapshots never fill your storage.
Every run is logged in the Jobs grid, the Time line page and the Errors page. You know what was snapshotted, when, and what failed.
Sections
Section titled “Sections”- Overview: introduction to the module and its dashboard widgets
- Jobs: manage AutoSnap jobs (see Jobs). Expanding a job row shows two tabs: Histories (past runs of the job) and Status (the snapshots currently present on the guests of the job)
- Time line: the last 10 days in which the jobs of the cluster ran, with the runs of each day
- Errors: the failed runs only, with start, end, duration and status. Selected rows can be deleted or exported to Excel
- Status: inventory of AutoSnap snapshots, grouped by label and VM with counts and size; selected snapshots can be deleted
A job defines which guests to snapshot, when, and how many snapshots to keep. Click the Label of a row to edit the job.
A run skips three kinds of guests:
- templates
- guests on a node that is offline
- guests that Proxmox VE cannot snapshot: those with a passthrough device or, for containers, a bind mount
The log of the run says which guests were skipped and why.
Job fields
| Field | Default | Purpose |
|---|---|---|
| Enabled | off | Schedule the job. A disabled job is not run by the scheduler, but can still be run with Snap. The scheduler runs a job only while the module setting Enabled is on too |
| Include RAM | off | Save the memory state of the VM in the snapshot |
| While VM/CT Running | off | Take the snapshot only on guests that are running |
| Max Parallel | 1 | Number of guests processed at the same time (1 to 10) |
| Label | - | Required. Letters and digits only. It becomes part of the snapshot name and identifies the snapshots of the job |
| Retention | - | Required. Number of snapshots to keep per guest (1 to 100); older snapshots with the same label are removed |
| Description | - | Required. Free text shown in the grid |
| Cron Schedule | */15 * * * * |
When the job runs (default: every 15 minutes) |
| Vm Ids | - | Required. Guests to snapshot: IDs, ranges, name wildcards, pools, tags, @all, with optional exclusions |
| Web API Hook EE | - | Second tab of the editor: HTTP calls fired on the snapshot phases. See Web API Hook |
The snapshot name is auto + label + timestamp and cannot exceed 40 characters. The editor refuses a label that is too long for the Timestamp Format of the cluster.
The timeout of each snapshot is 30 seconds. It is shown in the Timeout column and cannot be changed from the editor.
Actions on the selected job:
| Action | What it does |
|---|---|
| Snap | Runs the job immediately in the background, without waiting for the schedule |
| Purge Snapshots | After confirmation, deletes every snapshot with the job’s label on the guests of the job. The job itself is kept |
| Delete | Deletes the job. When On remove job remove snapshots in Proxmox VE is on (default), its snapshots are purged first |
| Export | Downloads the jobs grid as an Excel file |
Every run, purge and delete is tracked in the global Task Tracker with its log.
Widgets
Section titled “Widgets”| Widget | Content |
|---|---|
| Status | AutoSnap status |
| Size | Snapshot size over time. Empty on the clusters where the snapshot size calculation is off |
| Check | Failed snapshots in the last days |
| Info | Snapshot statistics and insights |
| Daily Status EE | Successful and failed snapshots per day (last 14 days) |
The Check widget has one widget setting, Days to analyze (default 60). It covers only the clusters where the module setting Enabled is on.
Settings
Section titled “Settings”Show all settings
Enabled
Turns the module on for the cluster. While it is off no job is run by the scheduler, whatever the Enabled switch of the job, and the Check widget skips the cluster. Everything started by hand stays available: Snap, Purge Snapshots and the deletion of snapshots. A job is scheduled when both this setting and the Enabled switch of the job are on
- Default: off
Search Mode
Which guests the Status page scans. Managed: only the guests targeted by the jobs. All: every guest of the cluster
- Default: Managed
Timestamp Format
Date format of the timestamp at the end of the snapshot name. A format that does not sort in time order is refused. Use fixed-width specifiers (yyyy, yy, MM, dd, HH, mm, ss), with the largest unit first. Use HH and not hh, and no quoted text
- Default:
yyMMddHHmmss
Keep history maintain after deletion snapshot in Proxmox VE
Number of extra run results kept in the history of a job. The history holds the job’s Retention plus this number of past runs
- Default: 10
- Minimum: 0
Max percentage storage (default 95%)
Skip snapshot creation if the target storage is more full than this percentage (1 to 100)
- Default: 95
On remove job remove snapshots in Proxmox VE
Delete the snapshots created by a job when the job itself is deleted
- Default: on
Notify
When to send a notification at the end of a run: None (never), Always, On Failure Only. Nothing is sent if no Notifier configuration is selected
- Default: None
Notifier
Notifier configurations that receive the notifications
Permissions
Section titled “Permissions”Assign these to a role under Security.
Module permissions
| Permission | Allows |
|---|---|
| AutoSnap | Open the module and its Overview page |
| Jobs, Time line, Errors, Status | Open the page with that name (one permission per page) |
| Job: Export | Export the jobs grid |
| Job: Create / Edit / Delete | Add, change and delete jobs |
| Job: Snap | Use the Snap button |
| Job: Purge Snapshots | Use the Purge Snapshots button |
| Status: Export / Delete | Export the snapshot inventory, delete the selected snapshots |
| Results: Export / Delete | Export and delete run results (Histories tab and Errors page) |
| Status, Size, Check, Info, Daily Status EE | Use the dashboard widget with that name (one permission per widget) |
| Edit Settings | Change the module settings |
The module also follows the cluster permissions on each VM (VM: Read and VM: Snapshot manager, see Security):
- Status lists only the snapshots of the VMs the user can read; deleting snapshots needs VM: Snapshot manager on each of their VMs.
- Jobs, Time line and Errors list a job only when the user can read all of its VMs. A job on
@all, a pool, a tag or a node needs Read on every VM, node and storage of the cluster. The snapshot sizes of Time line add up every VM of the cluster: they are shown only with that Read. - Snap, Purge Snapshots, deleting a job and saving a job need Read and VM: Snapshot manager on every VM of the job, also on the VMs a change removes; for
@all, a pool, a tag or a node, Read on the whole cluster. Otherwise the action stops with a message. - The picker of the VMs of a job suggests only the VMs the user can read, without
@all, pools, tags and nodes, and the @all button is hidden, unless the user can read the whole cluster. - The widgets and the Overview count all the VMs of a cluster: they are shown only on the clusters where the user can read every VM, node and storage.
A scheduled job runs without a user: the checks are made when the job is saved and when it is started from the page.
Proxmox VE privileges: the base (PVEAuditor) plus the following.
| Privilege | Used for | Without it |
|---|---|---|
VM.Audit (base) | List the guests, read their configuration and snapshots | The guest is not selected |
VM.Snapshot | Create and remove snapshots, also with Include RAM | The run fails |
Datastore.Audit (base) | Storage usage for Max percentage storage | The storage check is skipped and the snapshots are taken anyway |
Pool.Audit (base) | Select guests by pool | The pool selects no guests |
On Proxmox VE 8 and earlier the pool list needs Pool.Allocate in place of Pool.Audit.
VM.Snapshot also allows the rollback of a guest to any of its snapshots. AutoSnap never rolls back, but who holds the account can.
The base and the rules common to all modules are in Proxmox VE Permissions.
