Windows Server 2022 · pve-prod · pve-02 · IP 10.20.4.50
5 snapshots
| Name | Description | Size | Created | By | Actions |
|---|---|---|---|---|---|
clean-installPVE | Server 2022, sysprepped | — | Oct 2, 08:14 AM | Jonas Weber | |
domain-joinedPVE | Joined corp.example | — | Oct 3, 09:40 AM | Jonas Weber | |
pre-updatePVE | — | — | Oct 9, 05:05 PM | Mara Koch | |
kb-rolloutPVEcurrent | — | — | Oct 14, 06:30 AM | Jonas Weber | |
iis-testPVE | IIS role trial | — | Oct 11, 11:22 AM | Mara Koch |
Every VM gets a past it can go back to.
Owners create, roll back and delete snapshots from the VM page — Proxmox snapshots and LVM snapshots alike — and find every backup by day. Above is a VM’s Snapshots tab, with the branch graph from the sidebar’s Snapshots card. Try it.
Where does the disk live?
Nobody has to know. Verlocx looks at the storage of the VM’s largest disk and picks the backend — the owner just presses “Create snapshot”. Pick an answer to see where it goes.
Proxmox snapshots
through the Proxmox API- Shape
- A tree on LVM-thin, Ceph and qcow2 volumes. Each snapshot records its parent; rolling back to an older one keeps the later ones, and carrying on starts a branch.
- Memory
- Optionally with the guest's RAM state — via the Verlocx REST API (POST /api/v1/vms/{vmid}/snapshots, withRam: true).
- Rollback
- Returns the VM to the snapshot and keeps it. “Current” moves; nothing is consumed.
- Delete
- Children re-link to the deleted snapshot's parent. Verlocx re-reads the tree right away.
Needs: A connected Proxmox cluster — API token or admin account.
LVM snapshots
over SSH to the node- Shape
- One flat snapshot volume next to the disk: vm-2104-disk-0-snap. No chain.
- Size
- A copy-on-write volume with a fixed size — by default the size of the VM's disk.
- Rollback
- A merge into the disk, which consumes the snapshot. On a running VM it waits for a power-cycle.
- Name
- The volume name is fixed, so the name you type is kept in Verlocx as the description.
Needs: The cluster connected with the admin account, and a cluster endpoint given as a hostname — so each node is reachable over SSH as <node>.<domain>. Verlocx logs in on port 22 with that admin login.
Why can’t I snapshot a VM on raw LVM?
LVM snapshots need SSH to the node. Verlocx has it only when the cluster is connected with the admin account and its endpoint is a hostname. Without that — an API-token cluster, or an endpoint given as an IP — VMs on raw thick LVM can’t be snapshotted; VMs on other storages still get Proxmox snapshots.
# lvconvert --merge
On raw LVM, a rollback waits for a full power-cycle — and Verlocx waits with it.
# A running VM holds its disk open, so LVM queues the merge until the disk is next activated — a real Proxmox stop, then start. A reboot inside the guest doesn’t close it.
# Verlocx marks the snapshot “awaiting reboot”, checks more often, and refuses a new snapshot until the merge is done.
- #lvcreate -L 80G -s -n vm-2104-disk-0-snap /dev/vg-san/vm-2104-disk-0
- verlocxsnapshot "before-upgrade" created · LVM
- Snapshotvm-2104-disk-0-snap
- Merge issuedlvconvert --merge
- Awaiting rebootneeds a Proxmox stop, then start
- Mergedsnapshot consumed
The VM is running. Open the row’s ⋯ menu, Merge (restore), and see what LVM does with an open disk.
Windows Server 2022 · pve-prod · pve-02 · IP 10.20.4.50
1 snapshot
| Name | Description | Size | Created | By | Actions |
|---|---|---|---|---|---|
vm-2104-disk-0-snapLVM | before-upgrade | 80 GB | Oct 16, 09:12 AM | Jonas Weber |
Deleted means deleted.
Verlocx reconciles with the cluster all the time — and never lets a sync undo what someone just did.
- between sync passes
- 40 s
- Snapshots of every VM, both backends, reconciled with the cluster.
- while a merge waits
- 15 s
- Faster while an LVM rollback waits for its stop and start.
- a deleted name is remembered
- 5 min
- No pass that started earlier can write it back.
- a new snapshot is never pruned
- 2 min
- A pass that read the cluster before it existed can't remove it.
Will changes made in Proxmox show up?
Yes. Each sync pass reads every VM’s snapshots from the cluster, so a snapshot created or removed in Proxmox appears in Verlocx too.
Backups, by the day they were taken.
Every archive of the VM, read live from the cluster’s backup storages. Click a day, pick a point, restore — with a confirmation, and never over a running guest. Shut the VM down from its header in the mock to see the difference.
Joins the right job
Per template, a new VM is added to the matching Proxmox backup job as it’s deployed.
No inherited archives
A deleted VM’s VMID stays blocked — for a period set per project, or for good — so a new VM never picks up its backups.
Windows Server 2022 · pve-prod · pve-02 · IP 10.20.4.50
29 backups
| Date | Backups | Total size | Types | Status | Open |
|---|---|---|---|---|---|
Mon, Oct 19, 2026 Today | 1 backup | 42.1 GB | pbs-vm | completed | |
Sun, Oct 18, 2026 Yesterday | 1 backup | 42.2 GB | pbs-vm | completed | |
Sat, Oct 17, 2026 2 days ago | 1 backup | 42.3 GB | pbs-vm | completed | |
Fri, Oct 16, 2026 3 days ago | 1 backup | 42.4 GB | pbs-vm | completed | |
Thu, Oct 15, 2026 4 days ago | 1 backup | 42.5 GB | pbs-vm | completed | |
Wed, Oct 14, 2026 5 days ago | 2 backups | 81.8 GB | vma.zstpbs-vm | completed | |
Tue, Oct 13, 2026 6 days ago | 1 backup | 42.7 GB | pbs-vm | completed | |
Mon, Oct 12, 2026 1 week ago | 1 backup | 42.8 GB | pbs-vm | completed | |
Sun, Oct 11, 2026 1 week ago | 1 backup | 41 GB | pbs-vm | completed | |
Sat, Oct 10, 2026 1 week ago | 1 backup | 41.1 GB | pbs-vm | completed | |
Fri, Oct 9, 2026 1 week ago | 1 backup | 41.2 GB | pbs-vm | completed | |
Thu, Oct 8, 2026 1 week ago | 1 backup | 41.3 GB | pbs-vm | completed | |
Tue, Oct 6, 2026 1 week ago | 1 backup | 41.5 GB | pbs-vm | completed | |
Mon, Oct 5, 2026 2 weeks ago | 1 backup | 41.6 GB | pbs-vm | completed | |
Sun, Oct 4, 2026 2 weeks ago | 1 backup | 41.7 GB | pbs-vm | completed | |
Sat, Oct 3, 2026 2 weeks ago | 1 backup | 41.8 GB | pbs-vm | completed | |
Fri, Oct 2, 2026 2 weeks ago | 1 backup | 41.9 GB | pbs-vm | completed | |
Thu, Oct 1, 2026 2 weeks ago | 1 backup | 42 GB | pbs-vm | completed | |
Wed, Sep 30, 2026 2 weeks ago | 2 backups | 80.7 GB | vma.zstpbs-vm | completed | |
Tue, Sep 29, 2026 2 weeks ago | 1 backup | 42.2 GB | pbs-vm | completed | |
Mon, Sep 28, 2026 3 weeks ago | 1 backup | 42.3 GB | pbs-vm | completed | |
Sun, Sep 27, 2026 3 weeks ago | 1 backup | 42.4 GB | pbs-vm | completed | |
Sat, Sep 26, 2026 3 weeks ago | 1 backup | 42.5 GB | pbs-vm | completed | |
Fri, Sep 25, 2026 3 weeks ago | 1 backup | 42.6 GB | pbs-vm | completed | |
Thu, Sep 24, 2026 3 weeks ago | 1 backup | 42.7 GB | pbs-vm | completed | |
Wed, Sep 23, 2026 3 weeks ago | 1 backup | 42.8 GB | pbs-vm | completed | |
Tue, Sep 22, 2026 3 weeks ago | 1 backup | 41 GB | pbs-vm | completed |
Five keys, handed out one at a time.
Seeing your own VMs’ snapshots, seeing every VM’s, creating, rolling back and deleting are separate rights. Pick a built-in role to see which keys it holds. Built-in roles are locked; duplicate one to get your own copy and flip its switches.
Do owners need access to Proxmox?
No. Snapshots and backups are on the VM page, each action behind its own right — the portal does the hypervisor work.
5 built-in · 0 custom
Permissions · Operator
Built-in roles cannot be edited. Use to derive a custom role from this one.
15 of 62 granted
Snapshots
Point-in-time VM state. · 3/5
snapshot.view
List snapshots of VMs the user or group owns.
snapshot.view.all
List snapshots of every VM in the project.
snapshot.create
Take new snapshots.
snapshot.restore
Revert a VM to a snapshot.
snapshot.deletedangerous
Remove snapshots.
Backups
Scheduled and on-demand backups. Note: usage and creation are separate rights. · 2/6
backup.view
List backup points and jobs for VMs the user or group owns.
backup.view.all
List backup points and jobs for every VM in the project.
backup.repos.view
See the cluster-level backup Repositories tab.
backup.use
Restore a VM from an existing backup.
backup.create
Run or schedule new backup jobs.
backup.deletedangerous
Remove backup points.
Let owners undo their own changes.
Snapshots before every risky change, backups everyone can find — without handing out hypervisor access.