blog posts

If you’ve ever run a server, you know the half-second of hesitation before clicking „update.“ And you’ve probably heard two pieces of advice given in the same breath: take a snapshot first, and make sure you have a backup.

They sound like the same thing. Both are copies. Both promise to get you out of trouble. But treating them as interchangeable is one of the more expensive mistakes a server owner can make, because the difference only becomes obvious the moment you need to recover something and discover that what you saved isn’t what you need.

So let’s clear it up properly.

What a snapshot actually is

A snapshot is a record of what your disk or virtual machine looked like at one specific moment. The important word there is record, not copy.

When your hypervisor takes a snapshot, in most cases it doesn’t duplicate your data at all. It freezes the disk’s current state and writes every new change to a separate delta file. The original blocks stay untouched, sitting exactly as they were, ready to be handed back to you if you decide to roll back.

That design explains the two things everybody loves about snapshots. They’re nearly instant, because nothing large is being copied anywhere. And rolling back is just as fast, because the system simply discards the delta file and points at the frozen blocks again. Ten seconds to create, ten seconds to undo a disastrous update. Hard to beat.

It also explains the part people forget. The snapshot lives on the same storage as the original, and it depends on the original to make any sense. If that disk fails, if the storage node goes down, if someone deletes the virtual machine, the snapshot goes with it. A snapshot isn’t a second copy of your data in any meaningful sense. It’s more like a bookmark in the original’s life.

One nice extra: snapshots of a running VM can also capture memory state, so a rollback returns you to a machine that’s already up and running, not one that has to boot and recover.

What a backup actually is

A backup is a genuine, independent copy of your data written somewhere else. A different disk, a different server, object storage, another datacenter. The whole point of its design is that it survives the death of the machine it came from.

Because it’s a real copy, it costs more to create. A backup takes minutes or hours instead of seconds, and it consumes storage proportional to your data. Restoring takes time too, since the data has to travel back and be written again.

In exchange, you get everything a snapshot can’t give you. You can keep dozens of restore points stretching back months. You can restore onto completely different hardware, or at a different provider entirely. You can pull out one file, one database, or one mailbox instead of rewinding the entire machine. And you can survive events that take out the original server completely.

Most backup systems use a mix of full, incremental, and differential copies. A full backup copies everything. An incremental copies only what changed since the last backup of any kind, which keeps daily storage costs small. A differential copies everything changed since the last full backup, which uses more space but restores faster.

The differences that actually matter

Why old snapshots quietly cause problems

This is the part that surprises people. A snapshot isn’t free just because it was fast.

Once a snapshot exists, every write your server makes goes into the delta file, and that file grows. On a busy database server, it can grow alarmingly fast. Take several snapshots, and you build a chain, where reading a single block might mean walking backward through multiple layers to find the current version. Performance drops. Then one day the underlying storage fills up, and a full disk on a hypervisor doesn’t fail gracefully. It freezes the VM.

Deleting the snapshot isn’t instant either. The system has to merge all those accumulated changes back into the base disk, and merging a snapshot that’s been sitting there for three months is slow and genuinely risky.

The practical rule: treat snapshots as disposable and short-lived. Take one, do the work, verify things are fine, then delete it. Hours, not weeks.

What a snapshot will never save you from

• Storage or hardware failure. The snapshot was on the disk that just died.
• A deleted VM. Delete the machine, and its snapshots disappear with it.
• Ransomware with root access. Attackers know about snapshots. Deleting them is a standard step before encrypting anything.
• Problems you discover late. Corruption that started six weeks ago is beyond any sane snapshot retention window.
• Compliance requirements. Nobody accepts „we had a snapshot“ as a data retention policy.
• Migration. You can’t hand a snapshot to a different provider and ask them to load it.

When to reach for each one

Take a snapshot when you’re about to do something reversible and risky, and you want the option to undo it in the next few minutes:

• Kernel or OS updates
• Control panel upgrades, or changing a PHP version
• Editing a firewall or web server config you’re not confident about
• Testing a plugin, a theme, or a new application version
• The moment right before a migration cutover

Rely on a backup for everything that outlives the moment:

• Nightly protection of the whole server
• Database dumps you might need next month
• Anything you’d want after the server no longer exists
• Anything with a legal or contractual retention requirement
• Restoring one file for a client who deleted it and only noticed on Friday

Use them together, because that’s the point

The two aren’t competitors. They cover different failure modes, and a sensible setup uses both.

A workflow that holds up in practice looks roughly like this. Automated backups run nightly to storage that isn’t on the same machine, with sensible retention like daily copies for two weeks and weekly copies for a few months. Before any risky change, you take a snapshot, do the work, confirm the site or application actually behaves, then remove the snapshot. Snapshots never replace retention.

Two other habits are worth building. Follow the 3-2-1 rule: three copies of your data, on two different types of storage, with one of them somewhere else entirely. And test your restores. Actually restore something, at least quarterly. A backup you’ve never restored from isn’t a backup. It’s a hope, and hopes have a poor track record at 3 AM.

The short version

A snapshot is a fast rewind button for a machine that still exists. A backup is an insurance policy for a machine that might not.

Snapshots buy you speed and are perfect for short, risky operations. Backups buy you survival, portability, and time. If you only have the budget or patience for one, choose backups without hesitating, because a snapshot cannot rescue you from the failures that actually end businesses. Ideally, though, you keep both, and you use each for the job it was built to do.

FAQ