Introduction
Cloud data protection comes down to two tools every server operator needs to understand: snapshots and backups. These terms are often used interchangeably, but they work differently, serve different purposes, and should be used together — not as substitutes for each other.
A snapshot is a point-in-time image of your entire VM, captured almost instantly and stored so you can roll back your server to its exact previous state. A backup is a scheduled, independent copy of your data designed for long-term retention and recovery from serious failures. Knowing when to use each — and how to combine them — is the foundation of any solid data protection strategy.
This guide explains how snapshots and backups work under the hood, compares their trade-offs across key dimensions, and helps you build a protection plan that matches your actual risk tolerance. You will also see how Raff's data protection features map to each approach.
How Snapshots Work
A snapshot records the state of your VM's disk at a precise moment in time. Most cloud platforms, including Raff, implement snapshots using copy-on-write (COW) technology. When a snapshot is taken, the system does not immediately duplicate all your data. Instead, it marks the current state and tracks any new writes going forward. Only changed data is stored — the snapshot references the unchanged original blocks.
This design makes snapshot creation nearly instantaneous regardless of how much data is on your disk. A 200 GB server snapshot can be captured in seconds rather than the minutes or hours a full disk copy would require.
What Snapshots Are Good For
Pre-change insurance
Before applying a major OS update, installing new software, or making configuration changes that are difficult to reverse, take a snapshot. If something breaks, you can restore the entire server to its exact previous state in minutes.
Development and testing
Snapshots let you branch your server state. You can take a snapshot, run destructive tests or experiments, and roll back cleanly without any of the test changes persisting.
Snapshot Limitations
Because snapshots typically live on the same storage infrastructure as your VM, they share one critical weakness: if the underlying storage platform experiences a failure, both your live data and your snapshots may be affected simultaneously. Snapshots also accumulate storage costs over time as the difference between the snapshot state and your current disk grows. They are not a substitute for off-platform backups.
How Backups Work
Backups are scheduled copies of your VM's data that are stored independently of the source VM. Unlike snapshots, which are designed for near-instant capture and fast local rollback, backups are optimized for durability and long-term retention.
Raff's automated backup system lets you configure daily, weekly, or monthly schedules with retention periods ranging from 1 day to 365+ days. Backups run on a schedule you define and are stored separately from your VM's primary storage.
Full vs Incremental Backups
Cloud backup systems generally fall into two categories:
Full backups copy all data every time. They are simple to restore from because every backup is self-contained, but they consume more storage and take longer to complete.
Incremental backups copy only the data that changed since the last backup. They are faster and more storage-efficient but require the full backup chain to be intact for restoration.
Raff's backup system handles the full/incremental logic automatically — you configure the schedule and retention period, and the platform manages what is stored and how it is linked.
What Backups Are Good For
Backups are designed for recovery from serious failures: accidental data deletion, ransomware, application corruption that went unnoticed for days, and infrastructure-level disasters. Because backups are retained over time, they give you a history of recovery points — not just the most recent state.
Key Differences at a Glance
| Dimension | Snapshot | Backup |
|---|---|---|
| Creation speed | Seconds (copy-on-write) | Minutes to hours |
| Storage location | Same platform as VM | Independent storage |
| Best for | Short-term rollback | Long-term recovery |
| Retention | Manual | Scheduled |
| Infra failure protection | Limited | Strong |
| Restore speed | Very fast | Moderate |
Understanding RPO and RTO
Recovery Point Objective (RPO)
RPO defines how much data you can afford to lose.
- 24h → Daily backups
- 4–8h → Multiple per day
- Near-zero → Continuous backup
Recovery Time Objective (RTO)
RTO defines how fast you must recover.
Snapshots = faster
Backups = slower but safer
Define these first. Everything depends on them.
Best Practice Strategy
Use both.
Snapshots
- Before updates
- Before deployments
- Keep 2–3 max
Backups
- Daily or weekly
- Store off-server
- Retain 30–90 days
Test restores
- Monthly minimum
- Always verify data
How Raff Handles This
- Instant snapshots (no downtime)
- Automated backups (daily/weekly/monthly)
- Retention: 1–365+ days
- Restore or clone anytime
Simple, transparent, no hidden costs.
Common Mistakes
1. Using snapshots as backups
They are not.
2. Not testing restores
Untested backup = useless.
3. Too short retention
7 days is often not enough.
4. Ignoring databases
Use pg_dump / mysqldump.
5. Ignoring restore time
Test recovery speed.
When to Use What
Snapshot when:
- OS upgrade
- Risky change
- Deployment
Backup when:
- Production system
- Compliance needs
- Critical data
Both when:
- Serious workloads
Conclusion
Snapshots are for speed.
Backups are for safety.
Use both.
Start with your RPO → define backups
Then layer snapshots on top
Test everything.
Raff makes this simple — but strategy is still your responsibility.
