Snapshots vs Backups: Why Confusing Them Costs You Data

You take a snapshot before every deploy, it shows up in the dashboard as a restore point, and it rolls back a bad change in minutes. It feels like a backup. In one important way it isn't: a snapshot usually lives on the same storage as the thing it protects. When that storage, the volume or the account behind it goes, the snapshot can go too.

This article explains what each one is, the specific failures where the difference costs you data, and how to use both together. If you want the short definitions first, the glossary covers snapshot and backup.

What a snapshot actually is

A snapshot records the state of a disk or virtual machine at a moment in time. Most platforms do this with copy-on-write: instead of copying every block, the snapshot keeps a reference to the existing data and only stores blocks as they change afterwards.

That is why snapshots are fast to create and cheap to keep for a short while. It is also why they depend on the original. The snapshot and the live volume share the same storage system, and often the same underlying blocks.

On OpenStack, there are two kinds. An instance snapshot captures a whole virtual machine and is saved as an image. A volume snapshot captures a block storage volume and stays on the same storage backend as that volume.

Copy-on-write diagram showing a snapshot that stores only the two blocks changed since it was taken and points back to the live volume for the rest. — Copy-on-write snapshots preserve changed blocks while sharing unchanged data with the original volume.

What a backup actually is

A backup is an independent copy of your data, kept somewhere separate from the system it protects, for as long as your retention policy says.

Three properties separate a real backup from a convenient copy:

Independence. It can be restored even if the original server, volume and storage are gone.
Retention. It keeps a history long enough to go back past a problem you did not notice straight away.
Proof. Someone has restored from it recently and it worked.

A backup is slower to create and slower to restore than a snapshot. That is the price of not sharing a failure with the original.

InMotion Cloud includes snapshots and managed backups on every plan, and our managed services page lists what our engineers run for you.

Where the difference costs you data

Snapshots are excellent for undoing a change. They fail in the situations where you need recovery most.

The storage underneath has a problem. A snapshot on the same storage cluster shares that cluster's fate. Storage replication helps with failed disks: Ceph keeps three copies of each block, so losing a drive loses nothing. Replication copies mistakes just as faithfully as good data, though, so it does nothing for deletion or corruption.

The volume, instance or project is deleted. On many platforms, removing a volume or the project it sits in removes its snapshots with it. An instance snapshot saved as an image survives longer, but it still sits inside the same account.

Someone gets administrative access. Ransomware operators and malicious insiders go after recovery points first. Anything reachable with the same credentials as production can be deleted with them.

The problem started weeks ago. Snapshots are usually kept for days. If a bug has been quietly corrupting records for a month, every recent snapshot holds the corrupted version.

Snapshots pile up. Long chains of snapshots consume storage and, on some systems, slow down the volume they belong to. Teams that never prune them end up deleting in bulk under pressure, and sometimes delete the wrong ones.

Comparison showing a snapshot lost along with the storage cluster it shares with the live volume, while a backup on separate storage survives and can be restored. — A snapshot can share the source storage’s fate. An independent backup gives you another recovery path.

Table comparing snapshots and backups by storage location, creation and restore time, survival of storage or project loss, retention and best use. — Recovery depends on where a copy lives, how long it is retained and which failures it can survive.

How to use both

The two are not competitors. Used together, each covers the other's weak spot.

Snapshot before risky changes. Take one before a deploy, an upgrade or a migration step, and delete it once you are confident the change worked.

Back up on a schedule, with retention set on purpose. Daily copies for recent recovery, weekly and monthly copies for problems you find late.

Keep at least one copy outside production's reach. Separate storage at a minimum. Separate credentials or immutable storage if attackers are part of your threat model.

Restore something every quarter. Pick a non-critical system, restore it, time it, and write down what went wrong.

Weekly timeline showing nightly and weekly backups on a fixed schedule, with a short-lived snapshot taken before a Wednesday deploy and deleted the next day. — Keep snapshots around risky changes and retain scheduled backups for problems discovered later.

How it works on InMotion Cloud

On InMotion Cloud, snapshots are point-in-time copies of your virtual machines, taken on demand or on a schedule. They sit on the same storage platform as your volumes, which makes them the right tool for quick rollbacks. Our guide to volume snapshots and backups on OpenStack shows how to create each one.

Backups are part of the managed platform. They land in object storage inside your own project, on a replicated storage cluster that sits apart from the server being protected, and you can also send copies to a server of your own over SSH. You set retention across daily, weekly, monthly and yearly copies. Folder restores run from the dashboard, and full-server recovery happens with our engineers.

One limit, stated plainly. A separate copy is not the same as an immutable one. Independent storage protects you when a server or volume is lost. It does not stop someone with administrative access from deleting backups. We covered that trade-off in your continuity plan is only as good as your last restore.

Summary

Snapshots undo changes quickly because they share storage with the original. Backups survive losses because they don't. Use snapshots around risky changes, keep scheduled backups with deliberate retention on separate storage, and prove the backups work by restoring one.

Not sure which of your restore points would survive a bad day?

InMotion Cloud engineers will go through your snapshots and backups with you and check where each copy actually lives.

Talk to a cloud architect

Frequently asked questions

Is a snapshot a backup? Not on its own. A snapshot usually lives on the same storage as the original, so it does not survive the loss of that storage, volume or project.

When should I use a snapshot instead of a backup? Before a change you might need to undo quickly, such as a deploy or an upgrade. Delete it once the change is confirmed.

Are snapshots slower than backups to restore? Usually faster, because the data is already on the same storage. That speed comes from the same shared storage that makes them vulnerable.

Does storage replication replace backups? No. Replication protects against hardware failure by keeping extra copies of every block. It copies deletions and corruption just as faithfully.

How long should I keep snapshots? Days, not months. Long-lived snapshots consume storage and give a false sense of protection. Use backups for long retention.