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.Documentation Index
Fetch the complete documentation index at: https://docs.rafftechnologies.com/llms.txt
Use this file to discover all available pages before exploring further.
Side by side
| Snapshot | Backup | |
|---|---|---|
| When taken | On-demand, manually | Automated, on a schedule |
| Schedule | None | daily or weekly (with chosen time / day) |
| Retention | Until you delete it (or until the VM is deleted) | Configurable per schedule; first 3 backups per VM are free |
| Restore time (RTO target) | Fast — minutes for typical OS disks; restore creates a fresh VM disk from the snapshot | Similar — 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 for | One-off “known good” states; before risky changes | Routine protection without remembering to act |
| Pricing | Per-GB stored, billed continuously | Per-GB stored, plus the schedule. First 3 backups per VM free |
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
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
RPO and RTO targets
If you’re sizing your protection strategy:| Target | Snapshots | Backups |
|---|---|---|
| RPO (max data loss tolerance) | Whatever interval you manually take them at — could be 1 hour, could be 6 months | The 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 |
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
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
rsyncbetween 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
scp / rsync to your own infrastructure.
Related
Create a snapshot
Capture state on demand.
Enable backups
Configure a schedule.