Snapshots are not backups — what CSI snapshots actually give you

The most consequential confusion in Kubernetes storage is the conflation of “snapshot” with “backup.” A snapshot is not a backup; a backup is not a snapshot. This lesson establishes the distinction and the production discipline for combining them.

What a snapshot is

A snapshot is a point-in-time copy of a volume, stored on the same storage backend:

flowchart LR
    A[Volume] -->|snapshot API| B[Snapshot]
    B -->|same backend| C[Storage backend]

For CSI, the snapshot is a VolumeSnapshot CRD:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: postgres-snap-20260816
spec:
  source:
    persistentVolumeClaimName: data-postgres-0
  volumeSnapshotClassName: postgres-snap

The snapshot is a delta from the volume’s state at the moment of creation. It is stored on the same backend; it shares the backend’s failure modes.

What a backup is

A backup is an independent copy of the data, stored separately from the production backend:

flowchart LR
    A[Volume] -->|export| B[Backup]
    B -->|different backend| C[Object storage: S3, GCS, Azure Blob]

The backup is independent:

• It is on a different backend (different availability zone, different region, different cloud).
• It has its own access controls.
• It has its own retention policy.
• It can be restored even if the primary backend is destroyed.

What snapshots protect against

Snapshots protect against:

• Operator errors: a bad kubectl delete of a PVC can be rolled back from a snapshot.
• Application bugs: a database corruption caused by an application bug can be rolled back from a snapshot.
• Point-in-time recovery: a snapshot taken before a destructive operation can be restored.
• Fast rollback: snapshots are fast to create and restore (seconds to minutes).

What snapshots do not protect against

Snapshots do not protect against:

• Storage backend failure: if the backend fails, the snapshot fails with it.
• Region-wide outage: a snapshot in the same region as the volume is lost in a region-wide outage.
• Ransomware: a snapshot on the same backend can be encrypted by ransomware (the attacker has access to both).
• Operator error on the snapshot itself: a bad kubectl delete volumesnapshot deletes the snapshot.
• Compliance: snapshots on the same backend may not meet compliance requirements for offsite storage.

The snapshot is not a backup

A backup is independent of the production backend. A snapshot is not.

The production rule: snapshots are for fast rollback; backups are for disaster recovery. Both are needed.

The snapshot lifecycle

stateDiagram-v2
    [*] --> Available: snapshot created
    Available --> Restoring: restore PVC from snapshot
    Available --> Deleting: operator deletes snapshot
    Available --> [*]: retention policy expires
    Restoring --> Bound: new PVC bound
    Restoring --> Failed: restore fails

Snapshots have lifecycle states:

• Available: the snapshot is ready for use.
• Restoring: a PVC is being restored from the snapshot.
• Failed: the restore failed (e.g., the backend is unavailable).

The production pattern

flowchart LR
    A[Production database] --> B[Hourly snapshot<br/>CSI, 24h retention]
    A --> C[Daily file backup<br/>S3, 7d retention]
    A --> D[Daily logical backup<br/>S3, 30d retention]
    B --> E[Same backend]
    C --> F[Different backend]
    D --> F

Snapshots for fast rollback; backups for disaster recovery; both tested regularly.

Quiz

Production discipline

• A snapshot is not a backup. They are different things with different purposes.
• Snapshots are for fast rollback; backups are for disaster recovery. Use both.
• Backups must be on a different backend. S3, GCS, Azure Blob, or another cluster.
• Test backups regularly. A backup that is never restored is not a backup.
• Document the snapshot and backup policies. Every workload has a documented policy.