Velero backs up an entire cluster: Kubernetes resources and volumes together, for full disaster recovery. VolumeSnapshot, Kubernetes’ native snapshot API, answers a narrower and far more frequent day-to-day need: capturing a single persistent volume’s state at a point in time, never touching the resources around it.

What VolumeSnapshot captures, and what it ignores

VolumeSnapshot delegates the actual capture to the storage provider’s CSI driver, creating a Kubernetes object that references that snapshot without ever touching the Deployments, Services, or other resources using that volume. A snapshot taken on a database’s PVC says nothing about the state of the Deployment serving it: it’s a pure data capture, not a cluster state.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: db-snapshot
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: db-data

VolumeSnapshotClass: the CSI driver decides the actual mechanics

VolumeSnapshotClass references the CSI driver responsible for the capture, exactly like a StorageClass references the driver responsible for provisioning. The exact mechanics (full copy, incremental snapshot at the underlying storage level) depend entirely on that driver, not on Kubernetes itself.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-snapclass
driver: ebs.csi.aws.com
deletionPolicy: Retain

Not every CSI driver supports snapshots: checking this capability before designing a workflow that depends on it stays a required step, exactly like checking a CNI actually implements NetworkPolicy before relying on it.

The most common use case: cloning a volume for a test environment

An existing VolumeSnapshot lets you create a new PVC whose data comes directly from the snapshot, never touching the source volume: a complete, independent copy, useful for reproducing a database’s exact state in a test environment without risking production.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-data-clone
spec:
  dataSource:
    name: db-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 10Gi

This clone runs independently of the original volume from the moment it’s created: no continuous sync, no link maintained after the initial copy, an important difference from continuous replication.

What VolumeSnapshot never replaces

A VolumeSnapshot only backs up volume data, never the Kubernetes resources around it: an entirely destroyed cluster with its VolumeSnapshots intact leaves recoverable data but no Deployment, Service, or Secret definitions to bring it back to life. Velero and VolumeSnapshot answer two different, complementary needs, not one need in two forms: full cluster DR versus point-in-time data cloning.

Takeaway

VolumeSnapshot captures a persistent volume’s state at a point in time, delegating the actual mechanics to the storage provider’s CSI driver via VolumeSnapshotClass, never touching the Kubernetes resources using that volume. The most common use case clones a volume for a test environment from an existing snapshot, an independent operation with no ongoing link to the source volume. This mechanism never replaces a full cluster backup like Velero: both answer distinct needs, one of the storage tooling choices that come up the moment a Kubernetes migration needs to handle stateful data.