Applications change data constantly, and mistakes happen at the worst moments.

Programs that store information, such as databases, file servers, and content systems, keep their data on volumes. Every day that data changes. A developer may run a faulty script that corrupts records. An upgrade may change the format of the files in a way that cannot easily be reversed. A person may delete the wrong folder. When any of these things happen, the most valuable thing you can have is a copy of the data from just before the mistake.

Traditionally, making such a copy meant stopping the application and copying every file, which could take hours for a large disk. A snapshot takes a different approach. Modern storage systems can record the state of a volume in seconds, without copying all the data immediately, because they remember only what changes afterward. Kubernetes gives you a standard way to ask the storage system for such a snapshot, using ordinary Kubernetes objects and the same tools you already use for everything else.

The moments when snapshots shine

Snapshots are most valuable just before risky changes such as upgrades, migrations, and bulk edits. They are also useful for creating quick copies of production-like data for testing, for capturing a consistent starting point for a backup tool, and for investigating problems after the fact. They are cheap to create compared with full copies, which is why teams take them often.

Snapshots reuse the same ideas as normal Kubernetes storage, so a quick review helps.

Pods are temporary, but data often needs to live longer. Kubernetes therefore separates the request for storage from the storage itself. An application asks for storage through a PersistentVolumeClaim, which says how much space it needs and what kind. Kubernetes then finds or creates a PersistentVolume that satisfies the claim, and binds the two together. A StorageClass describes the kinds of storage that can be created on demand, and names the driver that knows how to create it.

Why CSI is essential for snapshots

The Container Storage Interface is a standard that lets storage vendors write their own drivers and plug them into Kubernetes without changing Kubernetes itself. The volume snapshot feature is built entirely on top of this standard. A driver tells Kubernetes whether it can create snapshots, and if it can, Kubernetes can ask it to do so. Older built-in storage plug-ins that are not based on this standard do not offer snapshots through this feature.

Snapshots mirror the claim, volume, and class pattern you already know.

Kubernetes models snapshots with three objects that deliberately look like their storage cousins. This symmetry makes the feature easy to learn: if you understand claims, volumes, and classes, you already understand the shape of snapshots.

flowchart TD
    PVC[PersistentVolumeClaim
the volume to protect] --> VS[VolumeSnapshot
the request, in a namespace]
    VSC[VolumeSnapshotClass
driver and deletion policy] --> VS
    VS |bound one to one| VSCON[VolumeSnapshotContent
cluster-wide record]
    VSCON --> STORE[Real snapshot in the storage system]
    VS --> NEWPVC[New PersistentVolumeClaim
restored from the snapshot]
        

How they bind together

A VolumeSnapshot and a VolumeSnapshotContent are bound one to one, just as a claim and a volume are. The snapshot is the namespaced request that developers work with. The content is the cluster-wide record of the actual snapshot sitting in the storage system. Once bound, the snapshot object can report the status of the real snapshot, and deleting the snapshot can, depending on policy, also remove the real one.

Snapshots are not part of the core cluster by default; several components must be present.

Unlike pods and services, the snapshot objects are not built into the core of Kubernetes. They are extensions, defined through custom resource definitions, which teach the cluster the new object types. On top of these definitions, two kinds of software must be running: a common snapshot controller and a helper attached to your storage driver.

sequenceDiagram
    participant U as User
    participant API as API Server
    participant SC as Snapshot Controller
    participant SS as Snapshotter Sidecar
    participant D as CSI Driver
    participant S as Storage System
    U->>API: Create VolumeSnapshot
    API->>SC: New snapshot object seen
    SC->>API: Create VolumeSnapshotContent
    API->>SS: New content object seen for my driver
    SS->>D: Ask driver to create a snapshot
    D->>S: Snapshot the volume
    S-->>D: Snapshot identifier
    D-->>SS: Done
    SS->>API: Update content status
    SC->>API: Update VolumeSnapshot status
        

The class decides which driver takes the snapshot and what happens when it is deleted.

A VolumeSnapshotClass is the counterpart of a StorageClass. It is created by a cluster administrator and referenced by snapshots that want to use it. It names the CSI driver that will take the snapshot, states a deletion policy, and may carry driver-specific parameters, such as which region to store the snapshot in or which secret holds credentials.

Delete versus Retain

The deletion policy is the most important setting in the class. With Delete, removing the VolumeSnapshot also removes the content object and the real snapshot in the storage system. This keeps things tidy and avoids forgotten snapshots that cost money. With Retain, removing the VolumeSnapshot leaves the content and the real snapshot in place, so an administrator can still recover the data later. Retain is safer against accidents and more costly if nobody cleans up.

From a short request to a ready snapshot, step by step.

The most common way to make a snapshot is dynamic creation. You create a VolumeSnapshot that names the claim to snapshot and, optionally, the class to use. Everything else happens automatically. The controller creates the content object, the sidecar calls the driver, the storage system records the snapshot, and the status is reported back to the object you created.

flowchart LR
    A[VolumeSnapshot created] --> B[Content object created]
    B --> C[Driver asked to snapshot]
    C --> D[Point in time recorded]
    D --> E{Extra work such as upload?}
    E -->|No| F[Ready to use]
    E -->|Yes| G[Cut but still processing]
    G --> F
        

A handful of status fields tell you everything about a snapshot’s health.

Every VolumeSnapshot reports its state in a status section. Learning to read it quickly saves time when something goes wrong. The status tells you whether the snapshot is usable, when it was taken, how big a volume you need to restore it, which content object it is bound to, and whether an error has occurred.

Cut versus ready

Some storage systems record the point in time almost instantly but then continue to work in the background, for example by uploading data to another location. The moment when the state is fixed is sometimes described as the snapshot being cut. Your application can resume normal writes after the cut without harming the snapshot. But the snapshot is not ready to use until the background work completes and the status turns ready.

Sometimes the real snapshot already exists before Kubernetes hears about it.

Dynamic creation starts from a claim and produces a snapshot. Pre-provisioned snapshots go the other way. A snapshot already exists in the storage system, perhaps taken by a storage administrator, a scheduled job outside Kubernetes, or another cluster. An administrator then creates a VolumeSnapshotContent that refers to that real snapshot by its identifier, and a VolumeSnapshot that points to the content by name. Kubernetes binds the two and the existing snapshot becomes usable from inside the cluster.

flowchart TD
    E[Existing snapshot in the storage system] --> C[Administrator creates VolumeSnapshotContent
with the snapshot identifier]
    C --> V[User creates VolumeSnapshot
naming that content]
    V --> B[Objects bind one to one]
    B --> R[Restore a new claim from the snapshot]
        

A snapshot becomes useful when you turn it back into a working volume.

In Kubernetes, you never overwrite an existing volume from a snapshot. Instead, you create a brand new PersistentVolumeClaim and tell it that its data source is the snapshot. The storage system then creates a new volume whose contents match the snapshot exactly, and Kubernetes binds it to the new claim. Your application can mount this new claim like any other. The original volume is untouched, which makes restores safe to try and easy to compare against.

sequenceDiagram
    participant U as User
    participant API as API Server
    participant P as Provisioner
    participant D as CSI Driver
    participant S as Storage System
    U->>API: Create claim with a snapshot as data source
    API->>P: New claim needs a volume
    P->>D: Create volume from snapshot
    D->>S: Build new volume from the recorded state
    S-->>D: New volume identifier
    D-->>P: Volume ready
    P->>API: Bind volume to the claim
    Note over U,S: The original volume and snapshot remain unchanged
        

Rules that must be respected

Two related features that answer slightly different questions.

A snapshot records a moment and lives as a separate object. A clone creates a new volume directly from an existing claim, without a separate snapshot object in between. Both give you a copy of the data as it was at a chosen moment, and both rely on the driver supporting the feature. They are cousins, and it helps to know when each fits.

A snapshot captures the disk, but does it capture the application’s mind?

A snapshot records the blocks on a disk at one instant. But an application, especially a database, does not always keep everything it knows on disk. It holds recent changes in memory and writes them to disk later. If you snapshot at a random moment, the disk may contain a half-finished picture: some changes written, some not. The snapshot is then crash-consistent, meaning it looks like the disk after a sudden power cut.

sequenceDiagram
    participant O as Operator or Tool
    participant A as Application
    participant K as Kubernetes Snapshot
    O->>A: Flush buffers and pause writes
    A-->>O: Ready, data safely on disk
    O->>K: Create the VolumeSnapshot
    K-->>O: Point in time recorded
    O->>A: Resume normal writes
    Note over A,K: The snapshot is application-consistent
        

Who does the pausing?

Kubernetes itself does not know how to pause your database. The snapshot feature deals with volumes, not applications. To get application consistency, you need something that talks to the application, such as a database operator, a backup tool with pre-snapshot and post-snapshot actions, or a job you write yourself. Many operators for popular databases include exactly this step.

The most important idea in this whole guide.

A backup is a copy of your data stored somewhere separate, so that it survives the loss of the original. Most volume snapshots do not meet this test. In many storage systems, a snapshot lives on the same storage system as the volume it protects, and it may even share physical blocks with it. If the storage system fails, is deleted, or is compromised, the snapshot can be lost together with the volume.

Turning snapshots into backups

Snapshots are an excellent starting point for a backup, because they provide a stable, consistent view that can be copied out slowly while the application keeps running. Backup tools take a snapshot, read data from it, send the data to separate storage such as an object store in another location, and then delete the snapshot. The snapshot gives consistency, and the copy gives safety.

Snapshots accumulate quietly, and deleting them safely matters.

Every snapshot consumes space, and the space it uses grows as the source volume changes. Over months, forgotten snapshots can add up to a large hidden cost. Kubernetes gives you the deletion policy to control what happens when you delete a snapshot object, but it does not decide when snapshots should be deleted. Retention, meaning how long to keep each snapshot, is a policy you must define yourself.

Finalizers that protect in-use snapshots

A finalizer is a marker that tells Kubernetes not to remove an object until some cleanup work is done. The snapshot feature uses finalizers to protect data in two situations. While a snapshot is being taken, the source claim is protected so it cannot be deleted mid-operation. While a snapshot is being used as the source for a restore, the snapshot is protected so that it cannot disappear before the new volume has been created. These protections prevent damaging races.

Everyday situations where a snapshot pays for itself.

Kubernetes can take a snapshot when asked, but it does not take them on a timetable by itself.

The core snapshot feature provides objects and a workflow, but not a scheduler. Nothing in the core will create a snapshot every night or delete old ones for you. If you want regular snapshots and automatic retention, you must add something that does the scheduling, such as a small recurring job, a database operator, or a dedicated backup and snapshot management tool.

flowchart TD
    T[Schedule fires] --> Q[Quiesce application if needed]
    Q --> S[Create VolumeSnapshot]
    S --> W[Wait for ready status]
    W --> R[Resume application]
    R --> P[Prune snapshots beyond retention]
    P --> A[Alert if any step failed]
        

Snapshots are cheap to create, but they are not free to keep.

Most modern storage systems create snapshots using a technique that records references to existing blocks rather than copying them. That is why a snapshot of a very large volume can take seconds. After the snapshot is taken, the system must keep the old versions of any blocks that change on the live volume, so that the snapshot can still show the earlier state. The more your data changes, the more extra space the snapshots consume.

A snapshot contains all the data of the volume it came from, so it deserves the same protection.

Snapshots are copies of data, and anyone who can read a snapshot can potentially read everything it holds. Because restoring creates a new volume with the same contents, permission to create snapshots and permission to restore from them are both effectively permissions to access the data. Security around snapshots must therefore match the sensitivity of the volumes themselves.

When a snapshot will not become ready, the answer is nearly always in the status, the events, or the controller logs.

Snapshot problems tend to fall into a few groups: the objects cannot be created at all, the snapshot is created but never becomes ready, or the snapshot is ready but a restore fails. Each group points to a different part of the system, and working through a short checklist usually finds the cause quickly.

Common restore problems

Reliable arrangements that teams use again and again.

flowchart TD
    V[Live volume] --> S1[Frequent snapshots
Delete policy, kept for days]
    V --> S2[Milestone snapshots
Retain policy, kept for months]
    S1 --> R1[Quick rollback after mistakes]
    S2 --> R2[Recovery to important points]
    S2 --> B[Copy out to separate storage]
    B --> D[Disaster recovery]
        

Habits that create false confidence and painful surprises.

A compact checklist for dependable snapshots.

How teams use snapshots in daily operations.

It is a namespaced object that requests, and later represents, a point-in-time copy of a volume. A matching cluster-wide VolumeSnapshotContent represents the real snapshot in the storage system.

Only CSI drivers that implement snapshot operations. The feature is built on the Container Storage Interface, so you must check your specific driver’s documentation for support and for any special limits.

With Delete, removing the VolumeSnapshot also removes the content object and the real snapshot. With Retain, the content and the real snapshot stay, so the data can be recovered or re-imported later.

Create a new PersistentVolumeClaim whose data source is the snapshot. The claim must be in the same namespace, request at least the restore size, and use a storage class of the same driver. The original volume is not changed.

Not by default. Snapshots are namespaced, so the restored claim must live beside them. Experimental features for cross-namespace use exist in some versions, and backup tools offer workflows for moving data between namespaces.

No. A snapshot usually lives on the same storage system as the volume and can be lost with it. A backup is a copy kept separately. Snapshots are a fast, consistent source for backups, not a substitute for them.

By default they are crash-consistent, like a disk after a sudden power loss. For application consistency, the application must be quiesced by an operator, a backup tool, or your own procedure before the snapshot is taken.

Common causes are a missing snapshot controller or sidecar, a class whose driver does not match the volume, an unbound source claim, or a storage-side limit. Read the status error, the events, and the controller and sidecar logs.

No. The core feature provides the objects and workflow only. Use a recurring job, a database operator, or a backup tool to create snapshots on a schedule and to remove old ones.

A snapshot is a saved record you can reuse for several restores. A clone creates a new volume directly from an existing claim, as it is right now, without a separate snapshot object.

Creating one is usually quick and has little effect. Keeping many snapshots of a busy volume can add storage overhead and, in some systems, some performance cost, so plan the frequency and retention.

The snapshot objects are deleted with the namespace. With the Delete policy, the real snapshots are removed as well. Use Retain and an external copy for anything you cannot afford to lose.

Volume snapshots give Kubernetes a standard, driver-independent way to record the state of a storage volume at a moment in time and to bring it back later. Three objects describe the feature: a namespaced VolumeSnapshot that you create, a cluster-wide VolumeSnapshotContent that represents the real snapshot, and a VolumeSnapshotClass that names the driver and the deletion policy. The whole system runs on top of CSI drivers, a common controller, and a helper sidecar.

Snapshots are fast and cheap to take, easy to restore into new claims, and excellent for safety points, test data, and as the starting point of backups. But they are not backups on their own, they are only as consistent as the application allows, and they quietly consume space as data changes. Retention, monitoring, restore drills, and copies stored elsewhere turn snapshots from a convenient feature into a dependable part of your data protection strategy.