Manual snapshots produce an on-demand Recovery Point for a Cloud VM. They include the root disk and, optionally, attached data volumes. Use snapshots before risky changes, or as a clone source for new VMs via restore.
On the server detail page, open the Snapshots tab. The first time you visit, an info banner reminds you that restoring a snapshot will stop the server briefly, roll back the disk, and start it again automatically.
Under Create Snapshot:
pre-deploy-2026-05-09.Snapshot before upgrading Postgres to 17.Use clear, dated labels. Recovery points are also tagged with a system-generated identifier (srp-20260509T162709Z) but the label is what you’ll see first in the list.
Three modes are offered. Root volume is always captured; the mode controls what else is included.
A green confirmation banner — Root volume is always included — appears regardless of mode.
For Selective volumes, the Select Data Volumes list appears with each attached volume’s:
testblockstorage)10 GB · vdc · /mnt/volume_<id>)Tick the boxes for the volumes to include. The header shows a running count (1 selected, 2 selected, …).
Each recovery point shows:
srp-<timestamp>).Root + 1 data disk, etc.).Click Details to inspect the captured disks (root vs. data, target devices, filesystem types) and copy mount instructions for any data volumes.
pg_start_backup, FLUSH TABLES WITH READ LOCK) before snapshotting, or stop the application briefly.Switch to the Recovery Points section at the bottom of the Snapshots tab. The new row should match your label and show Storage and Created values. If it shows Loading snapshots… or No snapshots yet, refresh after a few seconds.
Create button is disabled Enter a label — it’s required.
Snapshot stuck in progress
Open the Activity feed. A failed VM snapshot_create event will show with a message you can act on.
Selective volumes list is empty The VM has no attached data volumes. Either switch to Root volume only or attach a block storage volume first.