Understanding and Using Kubernetes Volume Snapshots

With the introduction of the snapshot controller in Kubernetes, users can now create snapshots for CSI drivers and cloud providers that support this feature. The API is generic and vendor‑agnostic, allowing exploration without deep knowledge of specific implementations.

Introduction

A snapshot captures the state of a filesystem at a specific point in time, enabling later restoration of that exact state. Snapshot creation is near‑instantaneous, and subsequent changes are written to different blocks. Snapshots share storage with the original data, so they are not a replacement for backups, but they provide more consistent backup sources.

To use snapshots, the snapshot-controller must be installed and the following CRDs defined in the cluster:

VolumeSnapshotClass – analogous to a StorageClass for snapshots.

VolumeSnapshotContent – analogous to a PV for snapshots.

VolumeSnapshot – analogous to a PVC for snapshots.

The CSI driver must support snapshot creation and provide the csi-snapshotter controller.

How Snapshots Work in Kubernetes

Key entities include VolumeSnapshotClass , which defines parameters such as the CSI driver and storage location, and VolumeSnapshot , which references the PersistentVolumeClaim to snapshot.

When a snapshot is taken, the CSI driver creates a VolumeSnapshotContent resource with its parameters (often a storage‑system ID). The snapshot controller then binds the VolumeSnapshot to the VolumeSnapshotContent , similar to the PV‑PVC relationship.

To restore data, a new PersistentVolume can be created with the snapshot set as its dataSource .

Configuration

The VolumeSnapshotClass lets you specify attributes such as the CSI driver name and cloud‑provider‑specific parameters. Example definitions exist for OpenStack, vSphere, AWS, Azure, LINSTOR, GCP, CephFS, and Ceph RBD.

Use Case 1: PVC Templates

Creating a PVC template with pre‑populated data and cloning it on demand can speed up development environments and enable multiple pods to process data on different nodes. The snapshot mechanism makes this transparent.

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-worker1
spec:
  storageClassName: linstor-ssd-lvmthin-r2
  dataSource:
    name: pvc-template
    kind: PersistentVolumeClaim
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Use Case 2: Snapshots for Testing

To safely test upgrades without affecting production, clone the existing PVC and create a snapshot of the pre‑upgrade state. If issues arise, you can revert by restoring the snapshot.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mypvc-before-upgrade
spec:
  volumeSnapshotClassName: linstor
  source:
    persistentVolumeClaimName: mypvc

After upgrading, the snapshot can be used as the data source for a new PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  storageClassName: linstor-ssd-lvmthin-r2
  dataSource:
    name: mypvc-before-upgrade
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Use Case 3: Consistent Backups with Snapshots

Snapshots enable consistent backups of running PVCs without pausing applications. Tools like Velero can automatically create snapshots, schedule hooks, and pause/resume workloads for better consistency. Some vendors (e.g., LINSTOR) provide built‑in backup to remote S3 storage.

Define a VolumeSnapshotClass with S3 parameters:

---
kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1
metadata:
  name: linstor-minio
driver: linstor.csi.linbit.com
deletionPolicy: Retain
parameters:
  snap.linstor.csi.linbit.com/type: S3
  snap.linstor.csi.linbit.com/remote-name: minio
  snap.linstor.csi.linbit.com/allow-incremental: "false"
  snap.linstor.csi.linbit.com/s3-bucket: foo
  snap.linstor.csi.linbit.com/s3-endpoint: XX.XXX.XX.XXX.nip.io
  snap.linstor.csi.linbit.com/s3-signing-region: minio
  snap.linstor.csi.linbit.com/s3-use-path-style: "true"
  csi.storage.k8s.io/snapshotter-secret-name: linstor-minio
  csi.storage.k8s.io/snapshotter-secret-namespace: minio
---
kind: Secret
apiVersion: v1
metadata:
  name: linstor-minio
  namespace: minio
immutable: true
type: linstor.csi.linbit.com/s3-credentials.v1
stringData:
  access-key: minio
  secret-key: minio123

Create a snapshot that will be pushed to the remote S3 server:

---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mydb-backup1
spec:
  volumeSnapshotClassName: linstor-minio
  source:
    persistentVolumeClaimName: db-data

To use the snapshot across clusters, define the corresponding VolumeSnapshotContent and VolumeSnapshot resources, specifying the snapshotHandle that identifies the storage‑system snapshot ID.

---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: example-backup-from-s3
spec:
  deletionPolicy: Delete
  driver: linstor.csi.linbit.com
  source:
    snapshotHandle: snapshot-0a829b3f-9e4a-4c4e-849b-2a22c4a3449a
  volumeSnapshotClassName: linstor-minio
  volumeSnapshotRef:
    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    name: example-backup-from-s3
    namespace: new-cluster
---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: example-backup-from-s3
spec:
  source:
    volumeSnapshotContentName: example-backup-from-s3
  volumeSnapshotClassName: linstor-minio

Finally, create a new PVC using the backup snapshot as its data source:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-data
  namespace: new-cluster
spec:
  storageClassName: linstor-ssd-lvmthin-r2
  dataSource:
    name: example-backup-from-s3
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Conclusion

Snapshots allow you to create consistent backups and clone volumes efficiently, reducing the need for manual data copying and improving storage utilization in Kubernetes environments.