August 21, 2026
9 min read
Table of Contents
By Kokil Thapa | Last reviewed: August 2026
Volume Snapshots in Kubernetes provide a standardized, storage-agnostic mechanism to capture point-in-time copies of PersistentVolumeClaims (PVCs) without stopping pods or duplicating entire datasets. While traditional mysqldump or file-level backups remain essential for logical consistency, native snapshots handle infrastructure-level recovery, cloning, and migration at petabyte scale. This guide covers the complete operational workflow for implementing Volume Snapshots in Kubernetes on modern CSI-compliant storage backends.
Quick answer: Volume Snapshots in Kubernetes are cluster-scoped resources managed by the CSI Snapshot Controller that create immutable, point-in-time copies of PVC data via the underlying storage driver. To use them, install the snapshot CRDs and controller, define a VolumeSnapshotClass matching your StorageClass, then apply a VolumeSnapshot manifest referencing your target PVC for instant, space-efficient backups.
How do Volume Snapshots in Kubernetes differ from traditional backups?
Before adopting this technology, it is critical to understand where Volume Snapshots in Kubernetes fit within a broader CI/CD pipeline setup and disaster recovery strategy. They are not a replacement for logical database dumps or application-aware backups; they are a complementary infrastructure primitive.
A traditional backup reads data through the application or filesystem layer, serializes it, and writes it to a separate destination. A snapshot, conversely, instructs the storage backend (AWS EBS, Ceph RBD, Longhorn, etc.) to record the current block state metadata. On most modern copy-on-write (COW) systems, this operation completes in seconds regardless of volume size because no data is physically copied until blocks are modified.
The trade-off is coupling: a snapshot typically cannot be restored to a different storage vendor or region without additional tooling. For Nepal-based clients running hybrid infrastructure—perhaps AWS EKS for production and on-premise Ceph for development—I always recommend combining both approaches. Use snapshots for rapid operational recovery and cloning; use logical backups for portability and long-term archival.
How do you install the snapshot controller and CRDs?
Unlike core Kubernetes objects, Volume Snapshots in Kubernetes require explicit installation of Custom Resource Definitions (CRDs) and an external snapshot controller. As of Kubernetes 1.32+ (stable in 2026), these components are no longer bundled and must be deployed separately. Skipping this step is the most common reason kubectl get volumesnapshot returns "no resources found" even when the API server accepts the manifest.
Install the CRDs
Apply the official CRDs from the kubernetes-csi/external-snapshotter repository. Pin to a specific release tag rather than using master:
> SNAPSHOTTER_VERSION=v8.2.0
> kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/${SNAPSHOTTER_VERSION}/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
> kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/${SNAPSHOTTER_VERSION}/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
> kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/${SNAPSHOTTER_VERSION}/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yamlDeploy the Snapshot Controller
The controller watches for VolumeSnapshot objects and orchestrates the CSI driver calls. Deploy it into the kube-system namespace:
> kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/${SNAPSHOTTER_VERSION}/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
> kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/${SNAPSHOTTER_VERSION}/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yamlVerify the controller pod is running and the CRDs are established:
> kubectl get pods -n kube-system -l app=snapshot-controller
> kubectl get crd | grep snapshot
volumesnapshotclasses.snapshot.storage.k8s.io 2026-08-20T10:00:00Z
volumesnapshotcontents.snapshot.storage.k8s.io 2026-08-20T10:00:00Z
volumesnapshots.snapshot.storage.k8s.io 2026-08-20T10:00:00ZIf you manage multiple clusters via GitOps (ArgoCD or Flux), add these manifests to your infrastructure repo rather than applying manually. On managed services like EKS, GKE, or AKS, verify whether the cloud provider auto-installs the controller; many now do, but version drift between the controller and your CSI driver causes silent failures.
How do you create and restore a VolumeSnapshot in Kubernetes?
Once the controller is healthy, creating Volume Snapshots in Kubernetes requires two resources: a VolumeSnapshotClass (cluster-scoped, analogous to StorageClass) and a VolumeSnapshot (namespace-scoped). The class defines which CSI driver handles the operation and any driver-specific parameters.
Define the VolumeSnapshotClass
This example targets AWS EBS. Adjust the driver field for your environment (ebs.csi.aws.com, rbd.csi.ceph.com, driver.longhorn.io, etc.):
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: ebs-snapshot-class
annotations:
snapshot.storage.kubernetes.io/is-default-class: "true"
driver: ebs.csi.aws.com
deletionPolicy: Retain # Use 'Delete' only if you want snapshots GC'd with the PVC
parameters:
type: gp3 # AWS-specific: snapshot inherits volume typeThe deletionPolicy field is critical. Set it to Retain for production databases so accidental PVC deletion does not destroy your recovery points. Use Delete only for ephemeral dev/test environments where cleanup automation is desired.
Create a Snapshot from an Existing PVC
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: mysql-prod-snap-20260821
namespace: production
spec:
volumeSnapshotClassName: ebs-snapshot-class
source:
persistentVolumeClaimName: mysql-data-pvcMonitor readiness. The READYTOUSE field must become true before the snapshot is safe for restoration:
> kubectl get volumesnapshot -n production
NAME READYTOUSE SOURCEPVC AGE
mysql-prod-snap-20260821 true mysql-data-pvc 2mRestore a PVC from a Snapshot
Restoration creates a new PVC populated from the snapshot. The original PVC remains untouched:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-data-restored
namespace: production
spec:
accessModes:
- ReadWriteOnce
storageClassName: gp3-encrypted
resources:
requests:
storage: 100Gi # Must be >= original snapshot size
dataSource:
name: mysql-prod-snap-20260821
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.ioA common mistake on real client projects is attempting to restore into a PVC smaller than the original. Kubernetes will reject the binding silently or leave the PVC in Pending. Always match or exceed the source capacity. Additionally, ensure the target StorageClass uses the same CSI driver as the snapshot; cross-driver restoration is not supported natively.
What are the limitations and best practices for production snapshots?
Volume Snapshots in Kubernetes solve specific problems brilliantly but introduce failure modes that catch teams off guard. Understanding these boundaries prevents costly outages.
| Consideration | Impact | Mitigation |
|---|---|---|
| Application Consistency | Snapshots are crash-consistent, not application-consistent. In-flight transactions may corrupt databases. | Use fsfreeze, Velero hooks, or database-native quiescing before snapshot creation. |
| Cross-Region/Vendor Restore | Snapshots are bound to their originating storage backend and region. | Use Velero with restic/kopia for portable backups; reserve snapshots for same-region DR. |
| Cost Accumulation | Cloud providers charge per GB-month of snapshot storage. Forgotten snapshots compound costs. | Implement TTL-based cleanup via CronJobs or Velero schedules. Tag all snapshots with project/env metadata. |
| Performance Impact | High-churn volumes experience write amplification during active snapshots. | Schedule snapshots during low-I/O windows. Monitor CSI driver metrics for latency spikes. |
| Retention Governance | Kubernetes has no native retention policy for VolumeSnapshots. | Externalize lifecycle management to Velero, Cloud Custodian, or custom controllers. |
For legal-tech platforms I've built handling sensitive case documents, we combine hourly snapshots for rapid rollback with nightly encrypted logical backups pushed to S3 Glacier. The snapshot handles accidental deletions or bad deployments within minutes; the logical backup satisfies compliance retention requirements and enables cross-cloud migration if needed. This layered approach aligns with guidance from experienced DevOps engineers in Nepal who manage mixed regulatory environments.
Automating Snapshot Lifecycle
Never rely on manual snapshot creation in production. Use Velero's scheduled backups with snapshot integration:
> velero schedule create mysql-hourly \
--schedule="0 * * * *" \
--include-namespaces=production \
--selector="app=mysql" \
--snapshot-volumes=true \
--ttl=168h # Auto-delete after 7 daysThis command creates hourly snapshots of all PVCs attached to pods labeled app=mysql in the production namespace, automatically cleaning up snapshots older than seven days. Velero also records metadata about which pods, configs, and secrets correspond to each snapshot, enabling coordinated application-level restores rather than orphaned volume recovery.
How do Volume Snapshots compare across major CSI drivers?
Not all CSI drivers implement snapshot functionality identically. Testing on actual infrastructure reveals significant behavioral differences that documentation often omits.
- AWS EBS: Snapshots are regional, incremental, and support fast snapshot restore (FSR) for large volumes. Restoration to a different AZ requires copying the snapshot first, adding 10–30 minutes for TB-scale volumes.
- Ceph RBD: Supports cloning directly from snapshots without intermediate restore steps, making it ideal for dev/test environment provisioning. Performance depends heavily on OSD count and network bandwidth.
- Longhorn: Offers recurring snapshot schedules natively within its UI, reducing dependency on external tooling. Snapshots are stored within the cluster, so monitor disk usage carefully to avoid node pressure.
- GCP Persistent Disk: Supports instant snapshots with minimal performance impact, but cross-project sharing requires IAM configuration that is easy to misconfigure.
When evaluating storage for a new project, test snapshot creation and restoration latency with realistic data volumes before committing. A 500GB PostgreSQL database that takes 45 minutes to restore from snapshot is functionally useless for sub-hour RTO targets, regardless of what the vendor documentation claims.
Implementing Volume Snapshots in Kubernetes for Production Reliability
Volume Snapshots in Kubernetes are a powerful primitive, but they demand disciplined operational practices to deliver real value. Install the controller and CRDs explicitly, validate CSI driver compatibility before relying on snapshot features, enforce application consistency through quiescing hooks, and automate lifecycle management to prevent cost sprawl. Treat snapshots as one layer in a defense-in-depth recovery strategy, not a silver bullet.
For teams managing stateful workloads on Kubernetes, investing time in proper snapshot architecture pays dividends during inevitable incidents. If you need hands-on assistance designing backup strategies for Laravel applications, legal-tech platforms, or eCommerce systems running on Kubernetes, reach out to discuss your infrastructure requirements.
Frequently Asked Questions
Volume Snapshots capture the state of a persistent volume at a specific point in time without copying all data immediately. They rely on underlying storage provider APIs to create consistent, restorable copies for backup or cloning purposes within the cluster.
Install the snapshot-controller and related CustomResourceDefinitions using kubectl apply against the official external-snapshotter repository release matching your Kubernetes version. Verify installation by checking that volumesnapshotclasses, volumesnapshots, and volumesnapshotcontents resources exist in the cluster before attempting any snapshot operations.
Most major cloud and storage CSI drivers support snapshots, including AWS EBS, GCE PD, Azure Disk, Ceph RBD, and Longhorn. Always check the specific driver documentation for enabled features, as some require explicit configuration flags or minimum driver versions to expose snapshot capabilities correctly to the Kubernetes API.
No, they are crash-consistent only, capturing disk state exactly as written at that moment without coordinating with running applications. For databases like MySQL or PostgreSQL, you must quiesce writes or use application-specific hooks before triggering the snapshot to ensure transaction logs and data files remain recoverable and uncorrupted.
Yes, but the VolumeSnapshotContent must have a DeletionPolicy of Retain and appropriate access controls configured. Create a new PersistentVolumeClaim referencing the snapshot source in the target namespace, ensuring the storage class matches and the CSI driver permits cross-namespace binding for security isolation.
Snapshots typically cost 20–30% of original volume pricing per GB stored monthly, varying by provider. On AWS EBS, standard snapshots run ~$0.05/GB/month (~NPR 6.70), while frequent snapshots of high-churn databases can accumulate costs quickly if old snapshots aren't pruned via retention policies.
Creation is usually near-instantaneous for cloud volumes since providers use metadata pointers rather than full copies. Initial completion may take seconds to minutes depending on volume size and current I/O load, but the snapshot becomes usable for restores almost immediately after the ReadyToUse status turns true.
Behavior depends on the VolumeSnapshotContent DeletionPolicy. If set to Delete, both the content and underlying cloud snapshot are removed automatically. If Retain, the cloud snapshot persists even after PVC deletion, allowing manual recovery but requiring explicit cleanup to avoid orphaned storage charges.
Use the VolumeSnapshotClass with an external scheduler like Velero or k8s-snapshooter, as Kubernetes lacks native cron-based snapshot scheduling. These tools define retention counts, frequency, and label selectors to automate backups consistently across namespaces without manual intervention or custom CronJob scripts.
Common causes include missing snapshot-controller deployment, incompatible CSI driver versions, insufficient IAM permissions for cloud snapshot APIs, or misconfigured VolumeSnapshotClass parameters. Check controller logs and CSI driver pods for errors, verify the storage backend supports snapshots, and confirm credentials allow snapshot creation operations.
They work well for point-in-time recovery within the same region but aren't sufficient alone for cross-region DR since snapshots typically reside in the source availability zone. Combine with replication tools or cross-region copy jobs for true disaster recovery, treating local snapshots as fast rollback mechanisms rather than complete business continuity solutions.
Only if you pause writes first using fsfreeze or database-native backup modes. Cloning an active database volume without quiescing produces inconsistent data that may fail recovery. For production systems, prefer pg_basebackup or mysqldump over raw snapshots unless your storage layer guarantees application-consistent snapshot coordination through specialized integrations.
Run kubectl get volumesnapshot and confirm STATUS shows ReadyToUse as true with a valid CREATIONTIME timestamp. Additionally inspect the bound VolumeSnapshotContent resource and validate the underlying cloud provider console shows the snapshot as available before relying on it for restores or compliance audits.
Volume snapshots preserve persistent data stored on PVs like databases and uploads, while etcd backups capture cluster state including deployments, configs, and secrets. Both are required for full cluster recovery; losing either means partial restoration at best, so maintain separate automated schedules and test restore procedures for each independently.
Use Velero for comprehensive cluster backups including manifests, PV data, and cross-cluster migration support with configurable retention. Native snapshots suit simple, storage-layer point-in-time captures without metadata overhead. In practice, most production environments combine both: Velero orchestrates scheduled backups while leveraging native snapshots as the underlying data capture mechanism.
