VPS Snaps
← All articles

Snapshot vs Backup: What Actually Protects Your Server

Snapshot vs Backup: What Actually Protects Your Server

Server host beside separate backup storage appliance

A snapshot is a fast, point-in-time marker that lets you roll a disk or VM back. A backup is an independent copy of your data stored somewhere else, so you can recover even when the original system, disk or account is gone. Snapshots are great for short-term undo. Backups are what you rely on when something really breaks. Most servers need both, and this guide shows where each one fits.

Vpssnaps
vpssnaps.com
Protect Server Data Beyond Snapshots
VPS Snaps automates encrypted, S3-compatible backups across cloud providers, with run logs that show successful operations and alert you to failures.
Register for VPS Snaps

TL;DR

  • A snapshot records the state of a disk at one moment and usually depends on the original storage. A backup is a separate, self-contained copy.
  • Snapshots give you the quickest rollback before a risky change. Backups protect you from failed disks, deleted accounts, corruption and ransomware.
  • A snapshot that lives next to its source fails together with it, so a snapshot alone is not a disaster recovery plan.
  • Run frequent, short-lived snapshots and scheduled backups that land in storage you own, then test a restore.
  • Before deleting a snapshot, confirm a newer verified backup exists and that nothing depends on the snapshot you are removing.

Table of Contents

The short answer: are snapshots backups?

Not by default. Computer Weekly’s storage primer puts it plainly: a snapshot records the state of blocks and files at a point in time and can roll storage back, but it is not a copy and not a substitute for backup.

The question “is a snapshot a backup?” gets muddy because cloud providers use the word “backup” loosely. A provider’s snapshot of a volume may be stored off the host in its own object storage, which makes it more durable than a hypervisor snapshot on the same datastore. Even so, it generally sits inside the same provider account, under the same billing relationship and the same access credentials as the server it protects. Lose the account, and you lose both.

The useful test is not the name on the button. It is these three questions:

  1. If the source disk or host disappears, can I still restore?
  2. If someone with access to my account deletes things, do I still have a copy?
  3. Have I actually restored from it and checked the result?

A true backup answers yes to all three. A bare snapshot often answers yes to none.

How a snapshot works

A snapshot freezes the view of your data at a given moment. Most implementations do not copy everything. They track which blocks change afterward, so the snapshot is mostly a map of the original data plus whatever has been preserved since. That is why snapshots are quick to create and cheap at first.

The tradeoff is dependency. TechTarget’s VM guide explains that snapshots generally rely on dependent local files, so a snapshot can be unusable if one of those files is unavailable. A backup, by contrast, is stored independently and can be recovered without those dependencies.

There is a performance cost too. Oracle notes that copy-on-write snapshots can increase production database I/O, because the first write to a block requires preserving the original block and writing the new one. On a busy database server, that overhead is not theoretical.

What snapshots are good at

  • Rolling back a failed upgrade, config change or deployment in minutes.
  • Creating a known-good restore point before touching a production server.
  • Cloning a server’s state to test something.
  • Frequent protection measured in minutes or hours, which Computer Weekly describes as the natural role for snapshots alongside daily backups.

Where snapshots fall short

  • They usually live on the same storage as the data they protect.
  • They often cannot be moved to another provider or restored without the original platform.
  • They can be consistent at the disk level but not at the application level, which matters for databases.
  • Long chains of old snapshots can slow storage and consume space nobody is watching.

How a backup works

A backup is a copy written to a separate location, designed to be restored on its own. It might be a full image, a set of files, a database dump, a volume archive, or a deduplicated repository. What defines it is independence: it does not need the original disk, host or hypervisor to exist.

Backups usually run on a schedule, keep multiple restore points under a retention policy, and can be encrypted and verified. They take longer to create and restore than a snapshot rollback, but they are the only thing that covers failures affecting the primary storage system. Computer Weekly frames the two as complementary tiers: snapshots for frequent, fast rollback, backups for longer-lived protection.

Database backups are a special case

Oracle’s guidance is blunt here. Storage snapshots lack awareness of database block structure and cannot validate data when they are created, so they offer no protection against undetected block corruption. Oracle recommends database-aware backups, and says snapshots left on the source array do not protect against array or media failure unless they are copied to secondary media.

The lesson applies beyond Oracle. For PostgreSQL, MySQL and similar engines, a logical dump or a database-aware backup tool gives you something you can inspect and restore on a different machine. A disk snapshot taken mid-write may restore into a database that needs crash recovery, or does not start.

Snapshot vs backup: side-by-side comparison

Criteria Snapshot Backup
What it is Point-in-time marker of disk or VM state Independent copy of data
Speed to create Seconds to minutes Minutes to hours, depending on size
Speed to restore Very fast rollback on the same platform Slower, but works anywhere you can restore to
Depends on source storage Usually yes No
Survives disk or host failure Often not Yes
Survives account compromise Rarely, same account Yes, if stored in separate credentials or storage
Typical retention Hours to days Days to years
Application consistency Disk-level unless coordinated Can be database-aware
Best use Pre-change safety net Disaster recovery and long-term history

Recovery speed, consistency and retention in practice

Recovery speed. A rollback from a snapshot can take moments because nothing needs to be copied back. A backup restore moves data across a network, so its time grows with the size of the dataset and the bandwidth you have. Plan your recovery expectations with that in mind, and measure the restore, not the backup.

Consistency. A snapshot captures what the disk looked like. If the application had unflushed writes in memory, the snapshot can reflect a half-finished state. Backups that pause or coordinate with the application, such as dumping a database properly, give you data you can trust more.

Retention. Computer Weekly notes that snapshot retention is commonly shorter than backup retention. That fits how they are used: you keep snapshots as long as the change window is open, and backups as long as you might need to go back. How far back is a business decision, and our guide to how long to keep backups walks through it.

Failure scope. This is the biggest gap. A snapshot protects against your own mistakes. A backup protects against the infrastructure, the provider account and the attacker. Our piece on why snapshots alone fail IT teams goes deeper on that distinction.

When to use a snapshot, a backup, or both

Use a snapshot when

  • You are about to upgrade a kernel, a control panel, a framework or a database version and want a quick way back.
  • You are cloning a server for testing. Oracle suggests using snapshots for development, QA or testing on secondary database copies rather than production storage.
  • You need a restore point during the hours around a deployment.

Use a backup when

  • The data matters tomorrow, next month or next year.
  • You need to recover into a different region, account or provider.
  • Compliance or customer contracts require retention history.
  • Ransomware or an accidental deletion could reach your primary environment. Our walkthrough of ransomware recovery with immutable copies covers the extra steps there.

Use both when

For nearly every production server, that is the answer. A practical pattern looks like this:

  1. Take a snapshot before every risky change and delete it after the change is verified.
  2. Run scheduled backups daily at minimum, more often for databases that change quickly.
  3. Send backups to a bucket you own, outside the server and ideally outside the provider hosting it.
  4. Keep several restore points, not just the latest.
  5. Run a test restore on a schedule and treat a failed one as an incident.

TechTarget’s perspective on VMs matches this: snapshots optimize short-term rollback, while independent backups are the right foundation for disaster recovery.

Can you restore a VM from a snapshot?

Yes, and it is often the fastest way to undo a bad change. The catch, per TechTarget, is that a snapshot can be unusable if a file it depends on is unavailable. That is fine for an undo button on a healthy host. It is not fine as your only plan for a lost host.

From a backup you can restore the whole VM, a single volume, or individual files and folders, and you can usually do it onto new infrastructure. That flexibility is what turns an outage into an inconvenience.

If you run on a major cloud, the details differ by platform. We cover provider specifics for DigitalOcean Droplet snapshots, Vultr snapshots, Hetzner snapshots and Azure VM snapshots and Azure Backup.

Is it safe to delete snapshots?

Often yes, and often you should. Old snapshots consume storage and, depending on the platform, can add overhead. But “safe” depends on what else is protecting you. Check these first:

  1. Is there a newer verified backup? If the snapshot is the only copy of a state you might need, do not delete it until a backup covers that point.
  2. Is the change it guarded confirmed good? Keep a pre-upgrade snapshot until the system has run normally through a full business cycle.
  3. Does anything depend on it? TechTarget’s point about dependent files applies in reverse: some platforms chain snapshots, and removing one in the chain can have side effects. Read your platform’s documentation on how deletion or merging works before you remove anything from a chain.
  4. Is it part of a policy or compliance requirement? If a contract or audit requires a restore point, record the decision before removing it.
  5. Will the deletion run during a busy period? On some platforms, merging data back can add load. Schedule it for a quiet window.

A simple rule that works: snapshots get an expiry the moment you create them. Backups get a retention policy. If you cannot say why a snapshot still exists, check whether a backup already covers it, then remove it.

Our perspective: where snapshot-only setups break

We see the same pattern with small teams and freelancers. Someone enables provider snapshots, sees a green check, and considers the server protected. It works until the day the problem is the account, the region, a deleted project or a credential that was leaked. The snapshot disappears with everything else.

Our perspective: where snapshot-only setups break — overview diagram

Our view is that a backup should satisfy three conditions. The data should stream into storage you own, not be staged somewhere you cannot see. Credentials should be stored encrypted. And every run should leave a log, so a failure is a visible event instead of a surprise discovered during a restore. If your restore depends on a vendor’s proprietary tool, you have swapped one dependency for another.

That is why we built VPS Snaps around provider snapshots plus backups that go into your own S3-compatible buckets. Snapshot artifacts stay in your provider account and can be restored without us. Snapshots are a good tool. They just are not the whole job, and the second half, the copy that survives the first half failing, is the one that people skip.

— Scott

Run both without the scripting

Stitching cron jobs, provider CLIs and database dumps together works until one of them quietly stops. VPS Snaps automates scheduled provider snapshots, database dumps, Docker volume backups, file backups and Kubernetes manifest and volume backups, across seven major cloud providers. Data streams directly into buckets you own, credentials are stored encrypted, retention is managed for you, and detailed run logs show every success and flag every failure.

Vpssnaps

Plans start free at $0 per month. Paid plans are Starter at $10 per month, Standard at $30, Pro at $57 and Agency at $117, or $120, $360, $684 and $1,404 per year respectively. See the details on the VPS Snaps pricing page, or read the server-focused version of this comparison first.

A starter plan for a small team

If you are setting this up from scratch, keep it boring:

  1. Inventory what matters. Databases, uploaded files, Docker volumes, configs, secrets. Our Linux server backup checklist is a good start.
  2. Pick a storage target you own. An S3-compatible bucket in a different account from your servers is ideal.
  3. Encrypt before it leaves. See how to encrypt backups with GPG and age if you roll your own.
  4. Set retention. Short for snapshots, longer for backups. The backup retention matrix helps you size it against ransomware dwell time.
  5. Get alerted on failure. A backup nobody notices failing is not a backup. Read how to know when a server backup fails.
  6. Restore on a schedule. Pick a date each quarter, restore to a scratch server, and check the application starts.

For wider planning, our small business backup strategy and Linux server backups guide cover the rest.

FAQ

What is the main difference between a snapshot and a backup?

A snapshot is a point-in-time record of a disk or VM that generally depends on the original storage. A backup is a separate, self-contained copy that can be restored even if the original system is gone. Snapshots are for quick rollback, backups are for recovery.

Is a snapshot a backup?

Not on its own. Oracle states that snapshots remaining on the source array do not protect against array or media failure, and recommends copying them to secondary media. A snapshot becomes part of a backup strategy only when it is paired with an independent copy.

Can I use snapshots instead of backups to save money?

You can for short-lived safety nets, such as the hours around an upgrade. For anything you need to recover after a host, account or region failure, you need an independent copy. The cost of a backup plan is usually far smaller than the cost of rebuilding lost data.

How often should I take snapshots and backups?

Computer Weekly’s guidance is snapshots for protection measured in minutes or hours and backups for daily protection. Adjust upward for databases that change constantly, and base the schedule on how much data you can afford to lose.

Do I need database-aware backups?

For production databases, yes. A disk snapshot cannot validate database blocks, so corruption can be captured without anyone noticing. A logical dump or a database-aware tool gives you something you can test and restore elsewhere.

Sources