Snapshots are not backups

The volume is gone. Controller failure, a fat-fingered rm -rf, a migration that went sideways — the cause barely matters at this point. You are still calm, because you remember taking a snapshot on Tuesday.

You open the console. The snapshot is gone too.

It was never a second copy. It was a bookmark inside the thing you just lost.

What a snapshot actually is

A snapshot is a point in time on a live volume. Most implementations are copy-on-write: the snapshot doesn’t duplicate your data, it records the blocks that have changed since you took it and points at the original blocks for everything else. That is why it is instant, and why it costs almost nothing to take.

That speed has a price, and the price is dependence. The snapshot references the same blocks on the same storage as the volume it came from. It is not a copy — it is a view. Lose the underlying storage and you lose the volume and every snapshot of it in the same stroke. The failure you were protecting against is precisely the failure that takes both.

None of which makes snapshots bad. They are excellent at the job they actually do. Take one before a kernel upgrade, a risky schema change, a migration you are not sure about. Roll back in seconds when it goes wrong. That is a real superpower and you should use it constantly.

It is just not protection. It is undo.

What a backup actually is

A backup is a self-contained copy that does not reference the original. A separate archive, written somewhere else, restorable onto a machine that did not exist when the backup was made. Delete the source volume, burn the host, lose the whole array — the archive is still an archive, and it still restores.

That gives you a single test, and it is the only one worth memorising:

If it cannot survive the destruction of the thing it is protecting, it is not a backup.

Run your data-protection strategy through that sentence. Most of what people call backups does not come out the other side.

Why every console blurs the line

Look at how these two things are presented to you. Same sidebar, usually under a heading like “Data protection”. Two buttons that look alike. One is instant and nearly free; the other is slow and metered. The interface implies they are two grades of the same product — quick save and slow save, express and standard.

They are not two grades of anything. They live in different failure domains, which is the only property that matters when you actually need them.

Nobody is quite lying to you. They just built a layout that does the implying, and let you draw the obvious wrong conclusion.

The restore nobody ran

Here is the harder truth: neither of them is protection until you have restored one.

A backup you have never restored is not a backup, it is a hypothesis. Untested archives fail in dull, specific ways — a volume that was never included, an archive that was truncated, a database that needed to be quiesced and instead got a torn write halfway through a transaction. You will discover which one applies to you on the single worst day of your quarter, at the exact moment you have no capacity to improvise.

So restore one. Not a checksum, not a “backup completed” green tick — an actual restore, onto a scratch machine, booted, logged into, queried. Once a quarter. Put it in the calendar like a fire drill, because that is what it is.

What we do instead

We keep the two apart, because they are apart.

A snapshot on Kaligon is a point-in-time state of your VM, held on the same storage as the disk, optionally including RAM. Instant, cheap, built for rollback. We call it a snapshot, and we do not call it protection.

A backup is a separate archive file, not a pointer into your live disk. It has its own retention, it can run on a schedule, and it restores to a new machine after the original is gone.

Both appear in the panel as exactly what they are. Neither is dressed up as the other, and we are not going to put them behind one button called “Protect” to make the product look simpler than the physics.

One caveat we would rather you heard from us: a backup sitting in the same region as the thing it protects is not a plan for losing that region. If regional failure is genuinely in your threat model, pull a copy out. Outbound traffic is a single flat rate you can read off the pricing page, so keeping your own copy somewhere else does not get punished at the border.

Take snapshots. They will save your afternoon.

Take backups. They will save your company.

Just never be confused about which one you took.