Blog

Snapshots: what they protect you from and what they don't

A practical guide to Excloud volume snapshots: point-in-time copies, restore workflows, accidental deletion protection, and where snapshots stop being backups.

17 June 2026 ยท updated 17 June 2026


Snapshots are one of those infrastructure features people only think about right after they needed one.

On Excloud, a snapshot is a point-in-time copy of a block volume. That makes it useful before a risky migration, before a package upgrade, before changing a filesystem, or before turning one good machine image into several new machines.

What snapshots protect you from

Snapshots help with operational mistakes.

Good examples:

  • A deploy writes bad data to disk.
  • A package upgrade breaks a service.
  • A migration needs rollback.
  • A config change makes a VM unbootable.
  • You want to clone a known-good volume into a new VM.

The workflow is intentionally plain:

exc compute snapshot create --volume_id <volume_id>

After that, restore from the snapshot when you need a new volume or a new root volume source.

What snapshots do not protect you from

Snapshots are not a complete backup strategy by themselves.

They do not automatically prove that your application can recover. They do not replace database-aware backups. They do not give you a tested restore runbook. They do not help if nobody knows which snapshot matters.

For databases, a crash-consistent volume snapshot may still need database recovery on boot. For critical data, pair snapshots with logical backups, export paths, and restore tests.

Backups vs snapshots

A snapshot is a fast infrastructure primitive. A backup is an operational promise.

A backup strategy answers:

  • What is copied?
  • How often?
  • Where is it stored?
  • Who can delete it?
  • How long is it retained?
  • How often is restore tested?

Snapshots can be part of that strategy, but they are not the whole strategy.

A useful snapshot habit

Before a risky operation, take a snapshot and name the reason in your deployment notes:

exc compute snapshot create --volume_id <volume_id>

Then write down:

  • The source VM.
  • The volume ID.
  • The snapshot ID.
  • The reason.
  • The expected cleanup date.

The cleanup date matters. Snapshots that nobody understands become expensive clutter.

The mental model

Use snapshots as a rollback handle, a clone source, and a safety point before risky work. Use backups as the durable recovery system for data you cannot afford to lose.