Volume Snapshots in Kubernetes

By Khimananda Oli | Last reviewed: August 2026

Stateful applications crash, databases corrupt, and bad deployments wipe data; relying solely on application-level dumps is too slow for modern recovery targets. Volume Snapshots in Kubernetes provide a storage-native mechanism to capture point-in-time copies of Persistent Volumes directly through the CSI interface, bypassing the need to stop pods or stream gigabytes over the network. This guide walks you through installing the necessary CRDs, configuring your storage driver, and executing reliable backup and restore workflows that actually work in production environments.

How do Volume Snapshots in Kubernetes differ from traditional backups?

Traditional backup methods for Kubernetes Persistent Volumes and storage often involve running pg_dump, mysqldump, or rsync inside a pod. These approaches are application-aware but suffer from significant operational drawbacks: they consume CPU and I/O on the production node, require consistent locking or quiescing, and scale poorly as dataset sizes grow into the terabytes. When managing PostgreSQL backup and restore with pg_dump, for example, you quickly hit limits where logical dumps take hours and block critical maintenance windows.

Volume Snapshots in Kubernetes operate at the storage layer, not the filesystem or application layer. The CSI driver instructs the underlying storage system (AWS EBS, Ceph RBD, Longhorn, etc.) to create a metadata pointer or copy-on-write clone. This happens in seconds regardless of volume size because no data is physically copied during the initial snapshot operation. The workload continues serving traffic with minimal performance impact.

However, snapshots are not a complete replacement for logical backups. They are crash-consistent by default, meaning they capture the disk state exactly as it was at that moment. For transactional databases, you must still ensure write ordering or use pre-snapshot hooks to flush buffers. Think of snapshots as your primary rapid-recovery mechanism and logical backups as your long-term archival and portability safety net. Both belong in a mature backup and disaster recovery strategy on the cloud.

How do you install and configure the Snapshot Controller?

The Kubernetes API server does not handle snapshot logic directly. You must install the external Snapshot Controller and the associated Custom Resource Definitions (CRDs). Most managed services like EKS, GKE, and AKS now include these by default in 2026, but self-managed clusters and older installations require manual setup.

Install the CRDs and Controller

Always verify compatibility between the snapshot controller version and your cluster version. As of mid-2026, v8.x is stable for Kubernetes 1.30+.

# Install VolumeSnapshot CRDs
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml

# Install the Snapshot Controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml

Create a VolumeSnapshotClass

The VolumeSnapshotClass tells Kubernetes which CSI driver handles snapshots for a given storage type. Without this, snapshot requests will remain pending indefinitely.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ebs-snapshot-class
driver: ebs.csi.aws.com
deletionPolicy: Retain
parameters:
  tagSpecification_1: "backup=true"

Set deletionPolicy carefully. Retain keeps the underlying cloud snapshot even if the Kubernetes VolumeSnapshot object is deleted—essential for compliance and accidental deletion protection. Use Delete only for ephemeral dev environments where cleanup automation is trusted.

How do you create and restore a VolumeSnapshot in Kubernetes?

Creating a snapshot is declarative. You define a VolumeSnapshot resource pointing to an existing PVC. The Snapshot Controller binds it to a VolumeSnapshotContent object representing the actual storage artifact.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: postgres-data-snap-20260813
  namespace: production
spec:
  volumeSnapshotClassName: ebs-snapshot-class
  source:
    persistentVolumeClaimName: postgres-data-pvc

Monitor readiness before attempting any restore operation:

kubectl get volumesnapshot postgres-data-snap-20260813 -n production
# NAME                           READYTOUSE   SOURCEPVC           SNAPSHOTCONTENT                            AGE
# postgres-data-snap-20260813    true         postgres-data-pvc   snapcontent-a1b2c3d4-e5f6-7890-abcd-ef12   2m

Restore from a Snapshot

Restoration creates a new PVC populated from the snapshot. Your application pod must be reconfigured to mount this new PVC. Never overwrite a running PVC in place; always restore to a new volume and validate before switching traffic.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data-restored
  namespace: production
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: gp3-encrypted
  resources:
    requests:
      storage: 100Gi
  dataSource:
    name: postgres-data-snap-20260813
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

Which storage drivers support Volume Snapshots in Kubernetes reliably?

Not all CSI drivers implement snapshot functionality equally. Some offer only basic create/delete, while others support restore, cloning, and cross-region replication. Choosing the right driver determines whether snapshots are a viable DR strategy or just a convenience feature.

In my experience auditing infrastructure for SOC 2 compliance, teams using NFS-based storage for databases consistently fail recovery time objectives because they cannot leverage Volume Snapshots in Kubernetes. If your stateful workload requires RPOs under 15 minutes, migrate to a block-storage CSI driver with native snapshot support. Longhorn is particularly strong for hybrid Nepal/global deployments where you need S3-compatible offsite backup without vendor lock-in.

What are common pitfalls when using Volume Snapshots in Kubernetes?

Snapshots introduce new failure modes that don't exist with traditional backups. Understanding these prevents data loss during actual incidents.

• Crash consistency vs. application consistency: A snapshot of a running PostgreSQL volume is crash-consistent, equivalent to pulling the power plug. The database will recover via WAL replay, but uncommitted transactions are lost. Always use fsfreeze or database-specific quiesce hooks before snapshotting critical data.
• Snapshot quota exhaustion: Cloud providers limit snapshots per volume and per region. Hitting these limits causes silent failures. Monitor volumesnapshot counts and set alerts before reaching 80% capacity.
• Orphaned VolumeSnapshotContents: Deleting a VolumeSnapshot with deletionPolicy: Retain leaves the cloud artifact intact but unmanaged. Over months, this creates significant cost drift. Implement automated tagging and lifecycle policies.
• Cross-namespace restore restrictions: By default, you cannot restore a snapshot from namespace A into namespace B. This is a security feature. Use Velero or custom RBAC if multi-namespace restore is required for platform engineering workflows.
• Ignoring restore testing: A snapshot you've never restored is not a backup. Schedule monthly restore drills into a staging namespace. Validate data integrity, not just PVC binding. This is non-negotiable for audit readiness.

Integrating Volume Snapshots in Kubernetes into Production Workflows

Adopting Volume Snapshots in Kubernetes effectively requires treating them as first-class infrastructure, not an afterthought. Define snapshot schedules via tools like Velero or Kasten K10 rather than manual YAML. Tag every snapshot with metadata (app, env, owner, compliance-scope) to enable automated lifecycle management and audit evidence collection. Integrate snapshot health checks into your Prometheus metrics monitoring fundamentals dashboard—track creation latency, ready-to-use ratio, and orphaned content count.

For teams operating under ISO 27001 or SOC 2, document your snapshot retention policy, encryption-at-rest configuration, and restore test cadence in your compliance evidence repository. Automate evidence generation where possible; auditors trust CI-generated artifacts more than wiki pages. Remember that snapshots complement, not replace, offsite logical backups. A ransomware event that encrypts your live volume may also encrypt accessible snapshots if IAM controls are insufficient. Air-gapped or immutable snapshot targets remain essential for true resilience.

If you're designing a stateful platform and need help architecting a snapshot strategy that meets both RTO/RPO targets and compliance requirements, reach out to discuss your infrastructure. Getting Volume Snapshots in Kubernetes right from the start avoids costly migrations and painful recovery failures later.