Skip to content
Devgo

Snapshot

A point-in-time copy of storage used for backups and recovery. Block snapshots are copy-on-write; DB snapshots are consistent dumps or WAL-based. Cheap to create, fast to restore, essential for DR.

When to use
  • Backups, DR, and pre-deployment safety nets.
  • Cloning data for testing.
When not to
  • As the only backup (test restores).
  • Long-term archival (use object storage).

Definition

A snapshot captures storage state at an instant. Block snapshots use copy-on-write (only changed blocks are stored). DB logical backups dump data; physical backups + WAL enable point-in-time recovery.

Why it exists

Full copies are slow and expensive. Snapshots capture a consistent point cheaply (copy-on-write stores only deltas), enabling fast recovery and testing without duplicating the whole dataset.

How it works

On snapshot, mark blocks as copy-on-write. Subsequent writes copy the old block to the snapshot first. Restoring reverts to that point. DB snapshots coordinate with WAL for consistency. Incremental snapshots chain off a base.

Scaling limits

Many snapshots increase write amplification (more COW) and management complexity. Restores of huge volumes take time. Snapshot consistency requires app coordination for in-memory state.

Cost shape

Storage for changed blocks (deltas). Blow-ups: high churn creating large snapshot deltas and retaining many snapshots.

Alternatives

  • Full backup — Simpler to manage, expensive in time and space.
  • Continuous replication — Near-zero RPO but no point-in-time flexibility.

Failure modes

  • Untested restores failing when needed.
  • High churn bloating snapshot storage.
  • Inconsistent snapshots of in-memory state.

, , ,