hourly, daily, weekly, or any name you choose. Each label keeps its own number of snapshots; the oldest are removed right after the new one is taken.
Up and running in 4 steps
- Install cv4pve-autosnap
- Create an API token
- Run
cv4pve-autosnap status - Take the first snapshots
Snapshots of your Proxmox VE guests, on a schedule
Runs outside the nodes, API only. One command takes a snapshot of the VMs and containers you choose and removes the oldest ones, so every label keeps exactly the number of snapshots you set.
By sysadmins, for sysadmins.
Built by Corsinvest, official Proxmox partner.
arch=$(uname -m | sed 's/x86_64/x64/;s/aarch64/arm64/;s/armv7l/arm/')wget https://github.com/Corsinvest/cv4pve-autosnap/releases/latest/download/cv4pve-autosnap-linux-$arch.zipunzip cv4pve-autosnap-linux-$arch.zipchmod +x cv4pve-autosnap./cv4pve-autosnap --host=pve01 --api-token='autosnap@pve!snap=…' --vmid=@all statuscurl -s https://api.github.com/repos/Corsinvest/cv4pve-autosnap/releases/latest | grep -o "https://[^\"]*-$(dpkg --print-architecture)\.deb" | xargs curl -LOsudo dpkg -i cv4pve-autosnap-*-$(dpkg --print-architecture).debcv4pve-autosnap --host=pve01 --api-token='autosnap@pve!snap=…' --vmid=@all statuscurl -s https://api.github.com/repos/Corsinvest/cv4pve-autosnap/releases/latest | grep -o "https://[^\"]*-$(rpm --eval %_target_cpu)\.rpm" | xargs curl -LOsudo rpm -i cv4pve-autosnap-*-$(rpm --eval %_target_cpu).rpmcv4pve-autosnap --host=pve01 --api-token='autosnap@pve!snap=…' --vmid=@all statusyay -S cv4pve-autosnapcv4pve-autosnap --host=pve01 --api-token='autosnap@pve!snap=…' --vmid=@all statusbrew install corsinvest/tap/cv4pve-autosnapcv4pve-autosnap --host=pve01 --api-token='autosnap@pve!snap=…' --vmid=@all statuscurl -s https://api.github.com/repos/Corsinvest/cv4pve-autosnap/releases/latest | grep -o "https://[^\"]*-$(uname -m)\.pkg" | xargs curl -LOsudo installer -target / -pkg cv4pve-autosnap-*-$(uname -m).pkgcv4pve-autosnap --host=pve01 --api-token='autosnap@pve!snap=…' --vmid=@all statusarch=$(uname -m | sed 's/x86_64/x64/')curl -LO https://github.com/Corsinvest/cv4pve-autosnap/releases/latest/download/cv4pve-autosnap-osx-$arch.zipunzip cv4pve-autosnap-osx-$arch.zipchmod +x cv4pve-autosnap./cv4pve-autosnap --host=pve01 --api-token='autosnap@pve!snap=…' --vmid=@all statuswinget install Corsinvest.cv4pve.autosnapcv4pve-autosnap --host=pve01 --api-token='autosnap@pve!snap=…' --vmid=@all status$arch = @{ AMD64 = 'x64'; x86 = 'x86'; ARM64 = 'arm64' }[$env:PROCESSOR_ARCHITECTURE]Invoke-WebRequest https://github.com/Corsinvest/cv4pve-autosnap/releases/latest/download/cv4pve-autosnap.exe-win-$arch.zip -OutFile cv4pve-autosnap.zipExpand-Archive cv4pve-autosnap.zip -DestinationPath . -Force.\cv4pve-autosnap --host=pve01 --api-token='autosnap@pve!snap=…' --vmid=@all statusPart of the real output on a test cluster: a job runs every two hours with the label 2hourly and
--keep=10, so each guest has its last ten snapshots.
| NODE | VM | TIME | PARENT | NAME | DESCRIPTION | VM STATUS |
|---|---|---|---|---|---|---|
| pve01 | 105 | 26/09/28 07:00:02 | before-upgrade | auto2hourly260928070002 | cv4pve-autosnap | |
| pve01 | 105 | 26/09/28 09:00:04 | auto2hourly260928070002 | auto2hourly260928090004 | cv4pve-autosnap | |
| pve01 | 105 | 26/09/28 11:00:07 | auto2hourly260928090004 | auto2hourly260928110007 | cv4pve-autosnap | |
| pve01 | 1000 | 26/09/28 07:00:03 | no-parent | auto2hourly260928070002 | cv4pve-autosnap | |
| pve01 | 1000 | 26/09/28 09:00:06 | auto2hourly260928070002 | auto2hourly260928090004 | cv4pve-autosnap | |
| pve02 | 203 | 26/09/28 07:00:57 | no-parent | auto2hourly260928070002 | cv4pve-autosnap |
The name is
auto + label + timestamp; both the timestamp and TIME are in the local time of the machine that runs the tool. VM STATUS is X when the snapshot includes the RAM (--state).A snapshot is the quickest way back when something goes wrong inside a guest: a package upgrade that breaks the boot, a bad configuration change, a script that deletes the wrong folder. Proxmox VE takes a snapshot in one click, but only when someone remembers to click, and it never removes the old ones. Snapshots that nobody removes pile up and fill the storage.
cv4pve-autosnap does both halves of the job: it takes the snapshot of every guest you select and removes the oldest ones of the same label, so a schedule of every two hours, keep 10 stays at ten snapshots per guest, forever. Run it from cron or the Windows Task Scheduler at fixed times, or from your own scripts right before an upgrade: no hand-written loop over the API to maintain.
A snapshot is not a backup
Section titled “A snapshot is not a backup”| Snapshot (cv4pve-autosnap) | Backup (vzdump, Proxmox Backup Server) | |
|---|---|---|
| Where it is | On the storage of the guest disks | On a separate storage |
| Survives the loss of that storage | No | Yes |
| Going back | Rollback in place, the guest returns to that moment | Restore, as the same or a new guest |
| Cost | Each snapshot keeps the blocks changed since it was taken: keep a few, for a short time | Space on the backup storage |
| Needs | A storage that supports snapshots: see the storage table | Any storage for the guest; a backup target |
Where it fits
Section titled “Where it fits”The cv4pve suite follows the Unix philosophy: each tool does one thing and does it well. cv4pve-autosnap keeps recent restore points of the guests. Its companion in continuous protection, cv4pve-node-protect, saves the configuration of the nodes, the part that guest backups do not cover.
Want the schedules, the history of the runs and HTTP webhooks from a web interface? cv4pve-admin runs the same engine as its AutoSnap module.
Outside the nodes, API only
Section titled “Outside the nodes, API only”cv4pve-autosnap runs outside the cluster (on your workstation, a management VM or a scheduled job) and talks only to the Proxmox VE REST API. Nothing is installed on the nodes and no SSH or root shell is needed: an API token with the four privileges in Permissions is enough. Give it more than one node and it connects to the first one that answers, so the snapshots still run while a node is down.
What it does for you
Section titled “What it does for you”By ID, name, range, node, pool or tag, with exclusions. The selection is read at every run, so a migrated or newly tagged guest is picked up with no change.
Before a snapshot, the usage of the storages holding the disks is checked: above 95% (or your threshold) the guest is skipped.
Your script runs at every phase (job start, before and after each snapshot and removal) with the guest, label and result in environment variables.
Warns when a VM has the QEMU guest agent off. With the agent, Proxmox VE freezes the guest filesystems during a snapshot without RAM; --state saves the RAM too.
--dry-run prints what would be created and removed, without touching the cluster.
Part of the cv4pve suite →
Made by Corsinvest,
official Proxmox partner
Take your first snapshots
Download the binary, try it with --dry-run, then schedule it.
Made by Corsinvest,official Proxmox partner
