Home / Blog / VPS and Infrastructure / Server Snapshots vs Backups
Ask a server owner what protects their data and you will often hear “I take snapshots.” It sounds reassuring, and snapshots are genuinely useful — until the day they are not enough. The distinction is simple and it matters: a snapshot is a point-in-time marker on the same storage system; a backup is an independent copy stored separately. If the storage fails, is wiped, or is encrypted by ransomware, snapshots stored on that same storage go with it.
This guide explains what each one does, when to use each, and how to combine them into a plan that actually recovers.
A snapshot captures the state of a disk or virtual machine at a moment in time — the files, the operating system, the configuration — so you can return to that exact state later. Modern snapshot systems are usually copy-on-write: taking the snapshot itself is fast, and only the blocks that change afterwards consume extra space. Rolling back is fast too, often a matter of minutes.
Their strength is speed and convenience. Their weakness is that they live where the live data lives.
A backup is a separate copy of your data, stored on different infrastructure from the original — a different server, a different storage system, a different location. A proper backup preserves version history, is recoverable even if the primary system is destroyed, and is ideally immutable or at least isolated enough that ransomware on the live server cannot encrypt or delete it too.
Backups are designed for disaster recovery and long-term retention: the copy you turn to when the server, the storage array, or the whole data centre is gone, when data was corrupted weeks ago, or when you need one file from last month rather than the whole machine from yesterday.
A backup usually includes files, databases, configuration (in /etc, web-server configs, cron jobs), SSL certificates, and application data — and it is only a backup if you have tested restoring it.
| Snapshot | Backup | |
|---|---|---|
| Where it lives | Same storage system as the live data | Separate storage, ideally off-site |
| Speed to create | Seconds to minutes | Minutes to hours, depending on size |
| Speed to restore | Very fast (whole machine rollback) | Slower (rebuild, then restore) |
| Survives storage failure? | No | Yes, if stored separately |
| Survives ransomware on the server? | Often no | Yes, if isolated/immutable |
| Retention | Short — days to a few weeks | Long — weeks to months or years |
| Granular restore | Usually whole-machine only | File, database and table level |
| Best for | Undoing a bad change | Disaster recovery, history, compliance |
The rule worth memorising, stated bluntly in the sources for this article, is: snapshots are not backups. Treat them as different tools and you will stop being surprised by what each one cannot do.
Three failure modes catch people out:
1. Shared fate. The snapshot and the live data share the same physical storage. If the array fails, the data centre loses power, or the volume is deleted, the snapshot is gone with the data it was meant to protect.
3. Scope. A snapshot rolls the whole machine back to a point in time. That is the wrong tool when you need one deleted file, one database table, or the state of the application without losing the orders that arrived since the snapshot was taken. Rolling a store back to yesterday also rolls back yesterday’s orders. A backup lets you restore the one thing you need without rewinding everything else.
The classic 3-2-1 rule still guides good backup design: keep three copies of your data, on two different media or systems, with one copy off-site. Modern commentary notes that the “two media” part matters less than it once did — what matters is isolation: the copies should not share a single failure domain, and at least one should be far enough away, and separate enough in access, that a single event cannot destroy them all.
In practice for a VPS or dedicated server, 3-2-1 looks like this:
Snapshots fit inside this picture as a fourth, fast layer — not as a replacement for any of the three copies.
A backup plan is a set of decisions, not a single tool. Decide each of these in writing:
What to back up. Files, databases, configuration, SSL certificates, cron jobs, and any application data outside the web root. Database dumps and file backups are different jobs — you need both.
How often. Match frequency to how much data you can afford to lose (your recovery point objective, or RPO). A brochure site may be fine with daily backups; a busy store may need hourly database backups and daily full backups. See How to Plan Backups for an Online Store for the store-specific version.
Where to store it. Off the server, in a different failure domain, with access credentials that are not stored on the server itself. If an attacker who roots your server can also delete your backups, you have one copy, not two.
How long to keep it. Daily copies for a week, weekly copies for a month, monthly copies for longer — a common retention ladder. Keep at least one copy from before any corruption could have started; ransomware can sit unnoticed for days.
How to test it. Schedule a restore test — to a staging server, not production — at least quarterly. A backup that has never been restored is a hope, not a plan. Record the time it takes; that is your real recovery time objective (RTO).
How to automate it. Use cron on Linux or Task Scheduler on Windows, and alert on failure. A backup job that fails silently for a month is worse than no job at all, because it creates false confidence.
For a small business server, a sensible routine is:
Do not store backups on the same server. The sources for this article are unanimous on that point, and it is the single most common mistake in VPS backup setups.
Snapshots give you a fast undo. Backups give you a way back when the machine itself is gone. Use snapshots before changes and delete them promptly; use backups for everything you cannot afford to lose, store them separately and off-site, and test the restore. A recovery plan is only as good as the last restore you actually performed.
For the server these protections run on, see our VPS hosting plans. [TO BE CONFIRMED: whether Offshore Hosting offers managed snapshots, off-site backups, or immutable backup storage, and on which plans.]
Containers package an application with everything it needs, so it runs the same way on any server. This guide explains what Docker containers are, when they help on a VPS, and the basics of running them well.
GPU hosting rents you a server whose graphics processor does the heavy lifting — for AI models, rendering and other parallel work. This guide explains who actually needs it, who does not, and what to check before buying.
A dedicated server gives you the whole machine — and the whole responsibility for it. Know exactly which jobs are yours before you sign, or pay for a managed plan.