Skip to main content
Updated May 8, 2026 Snapshots and backups both capture a VM’s disk state, but they’re built for different jobs. The short version: snapshots are manual restore points you take before risky changes, backups are scheduled protection that runs in the background. You can use both on the same VM.
Both snapshots and backups are deleted when you delete the VM. Verified in vm_deletion_processor.go — the deletion flow removes snapshots, backup schedules, AND backup files all together. If you need data to survive VM deletion, you have to copy it elsewhere first (Object Storage, an attached Volume that you keep, or scp it off). The VM is the lifecycle owner; its protections die with it.

​
Side by side

SnapshotBackup
When takenOn-demand, manuallyAutomated, on a schedule
ScheduleNonedaily or weekly (with chosen time / day)
RetentionUntil you delete it (or until the VM is deleted)Configurable per schedule
Restore time (RTO target)Fast — minutes for typical OS disks; restore creates a fresh VM disk from the snapshotSimilar — minutes
Data freshness (RPO)As fresh as the moment you clicked “Snapshot”At most one schedule interval (e.g. 24 hours behind for daily)
Best forOne-off “known good” states; before risky changesRoutine protection without remembering to act
PricingPer-GB stored, against the shared free poolPer-GB stored, against the shared free pool, plus the schedule

​
When to use a snapshot

  • Before upgrading kernel, OS, critical packages — quick rollback if the upgrade breaks something
  • Before a reinstall or factory reset
  • To clone a VM into a new VM (via the Save image as Custom Image flow — same machinery)
  • For a one-time “known good” state you’ll keep around as a recovery floor — e.g. right before a major migration
Snapshots are the manual tool. They’re cheap, fast, and capture exactly the moment you click. Use them liberally before any change you’re not 100% confident about.

​
When to enable backups

  • Production VMs where you can’t rely on remembering manual snapshots
  • Compliance / RPO requirements that mandate “no more than 24 hours of data loss” — a daily backup schedule meets that
  • Any VM where data loss between manual snapshots would matter — backups give you a guaranteed safety net even when nobody’s paying attention
  • VMs you’d want to restore to a point-in-time — backups are dated; pick the right day, restore from it
Backups are the always-on tool. They run on a schedule whether or not you remember to do anything. Backups and snapshots draw from a shared free-storage pool (50 GB + 10–15% of each VM’s disk), so a typical VM’s routine backup cycle stays free.

​
How backups are stored: incremental series

Each VM has a backup series. The first backup in the series is a full baseline; every subsequent backup stores only the blocks that changed since the previous one. You see each backup as a separate restore point in the dashboard and list response — pick any date, restore to it. Three things to know:
  • Sizes are small after the first one. A daily backup on a quiet VM is often a few MB. You’re billed only for what’s actually stored.
  • Restore points in a series depend on each other. To delete the oldest restore point without losing the newer ones, you need to delete the whole series (or wait for retention to age it out). The dashboard’s “Delete” button on a single restore point will surface this and offer to delete the whole series in one click.
  • You can start a fresh series whenever you want. Use Reset Backup Series — it closes the current series and the next backup will create a new baseline. Existing restore points stay restorable until you delete them.
Customers used to scheduled snapshots will recognize this model — Backup rows in the API now include an increment_id field so you can see the series structure programmatically. Legacy backups taken before this feature shipped have increment_id: null and behave exactly as they did before (standalone, no series).

​
RPO and RTO targets

If you’re sizing your protection strategy:
TargetSnapshotsBackups
RPO (max data loss tolerance)Whatever interval you manually take them at — could be 1 hour, could be 6 monthsThe schedule interval — daily ≈ 24h, weekly ≈ 168h
RTO (time to restore)Minutes for typical OS disks (the restore creates a fresh disk from the snapshot, then attaches and boots)Minutes — same restore mechanism
Both restore times scale roughly with disk size — 25 GiB OS disk in a couple minutes; a 1 TiB volume snapshot will take longer. There’s no fundamental difference between snapshot and backup restore speed; the difference is when the data was captured, not how fast it comes back.

​
Combining both — typical pattern

Many production VMs use both:
  • Daily backup schedule for routine protection — covers the “I forgot to snapshot before deploying” case
  • Manual snapshots before known-risky changes — kernel upgrades, schema migrations, OS reinstalls
Each tool is independent. The daily backup keeps running whether or not you take a manual snapshot, and the snapshot doesn’t replace the next scheduled backup.

​
What’s not a backup

A few patterns that aren’t real protection — clarifying so the difference is concrete:
  • A passive (stopped) VM — still consumes quota, still bills, but the disk lives on the same hypervisor as the running VM. A hardware-level loss takes both. Not a backup
  • A second VM created from the same template — fresh VM with no data; not a backup of anything
  • rsync between two VMs in the same VPC — useful for replication but the destination is also on the platform; if the platform has an issue both copies could be impacted
If you need protection that survives platform-wide events: copy data to Object Storage (different storage layer, different lifecycle), or pull copies off-platform via scp / rsync to your own infrastructure.

Create a snapshot

Capture state on demand.

Enable backups

Configure a schedule.
Last modified on June 18, 2026