# Server Snapshots vs Backups

- Link: https://offshorehosting.pk/server-snapshots-vs-backups/
- Published: 2026-10-25T10:28:00+00:00
- Author: admin

# 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.

## What a snapshot is

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.

 * Before an operating system upgrade or a major package update.
 * Before changing a firewall rule, a web-server configuration, or a database setting.
 * Before installing a plugin or an application update on a live server.
 * As a quick checkpoint before a risky migration step, so you can roll back if 
   the step fails.

Their strength is speed and convenience. Their weakness is that they live where 
the live data lives.

## What a backup is

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.

## The key differences at a glance

  |   |  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.

## Why snapshots fail as backups

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 3-2-1 rule, updated

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:

 1. **The live data** on the server.
 2. **A backup copy** on separate storage — another server, object storage, or a backup
    service — in the same region for fast restores.
 3. **An off-site copy** in a different region or with a different provider, retained
    longer, and ideally immutable so it cannot be altered or deleted by an attacker
    who compromises the live server.

Snapshots fit _inside_ this picture as a fourth, fast layer — not as a replacement
for any of the three copies.

## How to use snapshots well

 * **Take one before every risky change**, and name it clearly with the date and
   the reason (“before-php-8.4-upgrade-2026-10-25”).
 * **Delete snapshots promptly** once the change is proven good — usually within
   days. Old snapshots accumulate, consume space, and slow reads.
 * **Never keep a snapshot as your only copy** of anything important. If you cannot
   afford to lose it, it needs a backup.
 * **Test the rollback on staging first** if the change is complex. A snapshot you
   have never rolled back from is an untested assumption.
 * **Use snapshots as the source for a consistent backup.** A reliable pattern is:
   briefly pause writes (quiesce the application or database), take a snapshot, 
   resume the application, then run the backup _from the snapshot_. The live system
   is barely interrupted, and the backup reads a frozen, consistent state instead
   of a moving target.

## How to build a backup plan that works

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](https://offshorehosting.pk/blog/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.

## A combined routine for a typical VPS

For a small business server, a sensible routine is:

 * **Daily:** automated off-site backup of files and database, with a failure alert.
 * **Before changes:** a snapshot, deleted within a few days of the change proving
   good.
 * **Weekly:** a second backup copy to a different location or provider.
 * **Monthly:** a restore test to a staging server, documented with the time taken.
 * **Continuously:** monitor disk space, because both snapshots and backups fail
   when the disk is full — and a full disk can take the live server down too.

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.

## The bottom line

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](https://offshorehosting.pk/vps-hosting/)
plans. [TO BE CONFIRMED: whether Offshore Hosting offers managed snapshots, off-
site backups, or immutable backup storage, and on which plans.]

## Sources

 * High-Availability.com — Snapshots vs. Backups: Securing Your Data: https://blog.
   high-availability.com/episode-18-snapshots-vs-backups-securing-your-data/
 * MonoVM — How to Backup a Server or VPS: The Ultimate 2026 Guide: https://monovm.
   com/blog/how-to-backup-a-server-or-vps/
 * ComputerWeekly — The 3-2-1 backup rule: Has cloud made it obsolete?: https://
   www.computerweekly.com/feature/The-3-2-1-backup-rule-Has-cloud-made-it-obsolete?
   ref=filebase-blog
 * FOSS Linux — What Are System Snapshots in Linux? A Beginner’s Guide: https://
   www.fosslinux.com/162282/what-are-system-snapshots-in-linux.htm
 * LucidTrac — Safeguarding Business Continuity: Why Data Backups, Snapshots, and
   Rollbacks Are Mission-Critical: https://lucidtrac.com/blog/read/Safeguarding_Business_Continuity_Why_Data_Backups_Snapshots_and_Rollbacks_Are_Mission_Critical_Even_in_the_Cloud_Era

## Sources

 * https://blog.high-availability.com/episode-18-snapshots-vs-backups-securing-your-
   data/
 * https://monovm.com/blog/how-to-backup-a-server-or-vps/
 * https://www.computerweekly.com/feature/The-3-2-1-backup-rule-Has-cloud-made-it-
   obsolete?ref=filebase-blog
 * https://www.fosslinux.com/162282/what-are-system-snapshots-in-linux.htm
 * https://lucidtrac.com/blog/read/Safeguarding_Business_Continuity_Why_Data_Backups_Snapshots_and_Rollbacks_Are_Mission_Critical_Even_in_the_Cloud_Era