A Snapshot Is Not a Backup: The Difference That Costs You Data if Misunderstood
A snapshot is a fast rollback point on the same storage, a backup is an isolated copy somewhere else. Confusing the two costs you your data if the storage itself fails. We explain how each works, when a snapshot fails, and the correct rule.
The Direct Answer: They Are Two Different Things, Neither Replaces the Other
A snapshot is a point-in-time image of your server's disk state, usually stored on the same storage system that holds your original server. It lets you roll back entirely to that moment in seconds. A backup is a full, independent copy of your data stored in an isolated location, usually on completely different storage or a different server, and it can be restored even if the original server and its storage system are totally lost. The bottom line: a snapshot is a fast rollback tool, but it is not a backup, because it does not protect you from the failure of the storage it lives on.
This difference is not an academic detail, it is the difference between recovering your data or losing it forever. If you rely on snapshots alone and think of them as backups, then the storage disk fails physically or gets hit by ransomware that encrypts everything on that storage, your server and its snapshots may vanish in the same instant. The golden rule infrastructure engineers summarize as 3-2-1: keep three copies of your data, on two different media types, with at least one copy off-site and fully isolated. In this article we explain how each works technically, the exact scenarios where a snapshot fails, when to use which, and the practical options at Cloud.
How a Snapshot Works Technically
Most virtualization systems implement snapshots with copy-on-write. When you take a snapshot, the whole disk is not copied at once, instead its current state is frozen as a reference, and any new write after that is directed to new blocks while the old blocks are kept as they were at snapshot time. That is why a snapshot is taken in seconds and uses little space at first, growing as changes accumulate. This technique is brilliant for fast rollback, but note its essence: the old and new blocks are all on the same physical storage. A snapshot depends entirely on the integrity of the original disk, it is a reference inside it, not a copy outside it.
What a Snapshot Is Good At
- Speed: taking and restoring a snapshot takes seconds, not hours.
- Atomic rollback: it returns the whole system (OS, config, and data) to one consistent state.
- Low consumption: it does not consume space equal to the full disk at first.
How a Backup Works
A real backup reads your data and writes a copy of it to an independent destination: a separate backup server, object storage, or another data center. Because it is isolated, it stays intact even if the original server burns, its disk fails, or its data is encrypted. A good backup keeps several versions over time (retention), like a daily copy for seven days, so you can go back to any day, not just yesterday. This is critical against errors not discovered immediately, like a table that corrupted gradually or files deleted a week ago.
| Property | Snapshot | Backup |
|---|---|---|
| Storage location | Usually the server's own storage | Isolated independent storage |
| Protects against physical storage failure | No | Yes |
| Protects against ransomware on the same storage | No (may be encrypted with it) | Yes (isolated) |
| Take and restore speed | Seconds | Minutes to hours |
| Keeps multiple versions | Limited | Yes (7 days or more) |
| Best use | Before a risky change | Disaster recovery |
Scenarios Where a Snapshot Fails
1. The Storage Itself Fails
If the storage disk holding your server fails physically, your snapshots on it go with it, because they were references inside that storage, not copies outside it. This is the most dangerous misunderstanding: whoever thinks a snapshot is enough discovers the painful truth at the worst possible moment.
2. A Ransomware Attack
Modern ransomware specifically hunts for snapshots and local copies and encrypts or deletes them first before encrypting the data, because it knows they are the line of defense. Only an isolated copy out of reach of the compromised server survives.
3. Accumulating Wrong Deletion
If a developer accidentally deletes an important table, and you only notice a week later, yesterday's snapshot is useless because it was taken after the deletion. A backup with multiple versions returns you to before the disaster.
Two Metrics That Settle Your Plan: RPO and RTO
Before choosing a protection plan, define two numbers infrastructure engineers use to measure recovery readiness:
- RPO (Recovery Point Objective): how much data can you afford to lose? If your copy is daily, the maximum possible loss is a full day of data, so your RPO is 24 hours. If that is too much for an accounting or orders system, you need more frequent copies or real-time database replication.
- RTO (Recovery Time Objective): how long can your system stay down before it comes back? A snapshot gives you an RTO in seconds for a fast rollback, while restoring a large isolated copy may take minutes to hours depending on its size.
This is where it shows why you need both: the snapshot serves a very short RTO for simple mistakes, and the isolated copy serves a safe RPO and disaster protection. Define the two numbers by your business's sensitivity, then choose the retention period based on them, not at random.
The Snapshot's Impact on Performance
A point many overlook: leaving an old snapshot for weeks is not free. With copy-on-write, every new write to the disk needs to save the old block first, so the longer the snapshot lives and the more changes accumulate, the more space it uses and the heavier write operations become gradually. Hence the rule: a snapshot is a short-lived tool, take it before a risky change and delete it hours or days after confirming, do not leave it for months as if it were an archive. Long-term archiving is the job of the isolated backup, not the snapshot.
The Correct Usage Rule
Do not choose between them, use them together for their different roles:
- A snapshot before every risky change: before an OS upgrade, a major app update, or editing critical config, take a snapshot. If things go wrong, roll back in seconds. Delete the snapshot after you confirm the change succeeded, so it does not accumulate and eat space.
- A daily backup always: enable a separate daily backup with multiple versions, running automatically with no intervention, and stored isolated. This is your line of defense against real disasters.
- Test the restore: a copy you have never tried restoring is not a trustworthy copy. Do a full restore test occasionally to confirm the process actually works.
Practical Options at Cloud
On the cloud server from Cloud, backup is available as a direct add-on: a daily backup with 7-day retention for 800 SAR per year, or daily with 30-day retention for 2,000 SAR per year for those who want a wider rollback window. These are real isolated copies, not mere snapshots. As for managed cloud hosting on cPanel, daily, weekly, and monthly backups come included in all plans at no extra cost. All the data is inside the Kingdom on Riyadh servers at roughly 8ms latency, which matters for entities that require data sovereignty.
A Practical Conclusion
Your decision in four points:
- Never treat a snapshot as a backup, it is a reference on the same storage, not an isolated copy.
- Take a snapshot before any risky change, and delete it after confirming the change succeeded.
- Enable a daily isolated backup with multiple versions, and apply the 3-2-1 rule.
- Test a full restore periodically, an untested copy is an illusion until proven otherwise.
To enable an isolated backup for your server, check the pricing and plans and choose the retention period that fits your data's sensitivity.
