MeteorOps

DevOps Glossary

Kubernetes VolumeSnapshot

A Kubernetes VolumeSnapshot captures a point-in-time PVC copy for backup, restore, or storage cloning workflows.

Kubernetes VolumeSnapshot is a Kubernetes API resource that captures a point-in-time copy of a PersistentVolumeClaim, or PVC. In practical terms, it lets you take a storage-level snapshot of application data so you can restore it later, clone it into another PVC, or support backup workflows for stateful workloads.

What a Kubernetes VolumeSnapshot does

A VolumeSnapshot represents a snapshot request for a PVC. It does not copy Pod files by itself. Instead, Kubernetes asks the underlying storage system, through the Container Storage Interface, or CSI, driver to create the snapshot.

Teams use VolumeSnapshots to protect data for workloads such as:

  • PostgreSQL, MySQL, MongoDB, and other databases running in Kubernetes
  • Message brokers such as Kafka or RabbitMQ
  • CI systems, artifact stores, and internal developer tools
  • Data processing platforms such as Apache Airflow, including clusters deployed on EKS as shown in this guide to deploy Apache Airflow on AWS Elastic Kubernetes Service

How it works

VolumeSnapshot relies on the CSI snapshot feature. The basic flow is:

  1. You create a VolumeSnapshotClass that defines which CSI driver handles snapshots and what deletion policy to use.
  2. You create a VolumeSnapshot that points to an existing PVC.
  3. Kubernetes asks the CSI driver to create the actual storage snapshot.
  4. The driver creates a VolumeSnapshotContent object that maps the Kubernetes snapshot to the provider-side snapshot.
  5. You can later restore the snapshot into a new PVC.

For example, on AWS EKS with the Amazon EBS CSI driver, a VolumeSnapshot of an EBS-backed PVC usually maps to an EBS snapshot in AWS. On other platforms, the same Kubernetes API may map to snapshots in systems such as Google Persistent Disk, Azure Disk, Ceph RBD, or other CSI-supported storage backends.

Key related resources

  • PersistentVolumeClaim: The storage claim used by a Pod. A VolumeSnapshot usually captures the data behind a PVC.
  • VolumeSnapshot: The user-facing Kubernetes object that requests or represents a snapshot.
  • VolumeSnapshotClass: Defines the snapshot driver and policy, similar to how a StorageClass defines dynamic volume provisioning.
  • VolumeSnapshotContent: The cluster-level object that represents the actual snapshot created by the CSI driver.
  • CSI driver: The storage plugin that implements snapshot creation, deletion, and restore behavior.

Common use cases

  • Backup and restore: Take snapshots before risky releases, database migrations, or infrastructure changes.
  • Data cloning: Create a new PVC from a snapshot for staging, QA, or debugging.
  • Disaster recovery workflows: Combine snapshots with off-cluster backup tooling and provider-side retention policies.
  • Pre-upgrade safety: Snapshot stateful data before cluster or workload upgrades. This is especially useful when planning Kubernetes upgrades for startups.
  • Testing production-like data: Clone recent data into isolated environments without directly touching the live PVC.

Example manifest

This example creates a snapshot of an existing PVC named postgres-data:

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

To restore from that snapshot, you create a new PVC and use the snapshot as the data source:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data-restore
spec:
  storageClassName: gp3
  dataSource:
    name: postgres-data-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

Benefits

  • Kubernetes-native workflow: You can manage snapshots with standard Kubernetes manifests, GitOps, CI/CD, or infrastructure tools.
  • Faster restores: Storage snapshots are often faster than file-by-file backup and restore, depending on the backend.
  • Consistent API: The VolumeSnapshot API gives teams a common pattern across storage providers that support CSI snapshots.
  • Useful for automation: Platform teams can include snapshots in release pipelines, upgrade runbooks, and self-service recovery workflows.

Tradeoffs and limitations

  • Application consistency is not automatic: A snapshot captures storage state at a point in time. Databases may still need flushing, locking, checkpoints, or backup-aware tooling for clean recovery.
  • CSI support is required: Your storage driver must support Kubernetes snapshots. Not every driver or storage class does.
  • Snapshots are not always full backups: Provider-side snapshots may depend on the storage backend, region, account, or retention policy.
  • Restores usually create a new PVC: Kubernetes commonly restores a snapshot into a new claim rather than overwriting the original PVC in place.
  • Cost and retention still matter: Cloud snapshots can accumulate cost if you do not expire old snapshots.

VolumeSnapshot vs backup

A VolumeSnapshot is a Kubernetes object for creating a storage snapshot. A backup is a broader recovery process. A real backup strategy may include snapshots, off-site copies, retention rules, encryption settings, restore testing, and application-specific consistency steps.

For example, taking a VolumeSnapshot before a database migration can help you recover quickly if the migration fails. For long-term disaster recovery, you may still need scheduled backups, cross-region copies, and tested restore procedures.

How it fits with infrastructure workflows

Platform teams often manage VolumeSnapshot resources beside other Kubernetes and cloud infrastructure definitions. For example, you might define the storage class, snapshot class, database StatefulSet, and restore PVC in the same GitOps repository.

If your team already provisions Kubernetes resources with infrastructure-as-code, the same model can apply to snapshot-related objects. This guide on how to deploy Kubernetes resources using Terraform shows the kind of workflow that can include PVCs, snapshot classes, and restore manifests.

In clusters where Kubernetes manages cloud resources through APIs such as Crossplane, storage and recovery workflows may sit beside cloud resource definitions. For a related pattern, see this guide on how to deploy AWS resources using Crossplane on Kubernetes.

Simple real-world example

A startup runs PostgreSQL in Kubernetes using a PVC backed by a cloud block volume. Before applying a schema migration, the platform team creates a VolumeSnapshot of the database PVC. The migration fails and corrupts part of the application data. Instead of rebuilding the database from a slow logical backup, the team creates a new PVC from the snapshot, starts PostgreSQL against the restored volume, verifies the data, and points the application back to the recovered database.

The snapshot did not replace proper backups, but it gave the team a fast rollback path for a specific operational risk.