Volume Snapshots

Explore this Page

• Overview
• Requirements
• Volume Snapshots for Replicated PV Mayastor
• Volume Snapshots for Local PV LVM
• Volume Snapshots for Local PV ZFS
• Benefits of Volume Snapshots

Overview

Volume Snapshots enable point-in-time, consistent copies of persistent volumes managed by storages such as Replicated PV Mayastor and Local PV ZFS. These snapshots are critical for data protection, backup and restore, disaster recovery, and migration use cases in Kubernetes environments.

DataCore Puls8 supports copy-on-write (COW) based snapshots that capture only the changed blocks, thereby improving storage efficiency. Snapshots can be created, listed, and deleted using standard Kubernetes commands.

Typical use cases include:

• Backup and disaster recovery
• Application cloning and testing
• Rollbacks or troubleshooting

Snapshots are:

• Consistent: Data remains consistent across all volume replicas.
• Immutable: Once created, snapshot data cannot be altered.

Snapshots are not reconstructable in the event of node failure, unlike volume replicas.

Requirements

Before using Volume Snapshots, ensure the following requirements are met:

• Kubernetes cluster with CSI snapshot CRDs installed.
• CSI Snapshot Controller is deployed and running.
• DataCore Puls8 is installed and configured with:
  • Replicated PV Mayastor
  • Local PV LVM
  • Local PV ZFS
• DiskPools are created and operational (For Replicated PV Mayastor).
• A PVC is deployed using a compatible StorageClass.

DataCore Puls8 deploys a snapshot controller by default. If the cluster already manages its own, refer to Using an Existing Snapshot Controller in the section for the storage you are using.

Volume Snapshots for Replicated PV Mayastor

This section explains how to create, manage, and validate volume snapshots for persistent volumes provisioned by Replicated PV Mayastor. These snapshots are block-level, application-consistent, and support advanced storage capabilities such as incremental backup and thin provisioning.

Creating a StorageClass

cat <<EOF | kubectl create -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mayastor-3
parameters:
  protocol: nvmf
  repl: "3"
provisioner: io.openebs.csi-mayastor
EOF

Create and Verify a PVC

kubectl get pvc

NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     AGE
ms-volume-claim     Bound    pvc-fe1a5a16-ef70-4775-9eac-2f9c67b3cd5b   1Gi        RWO            mayastor-3       15s

Copy the PVC name (ms-volume-claim in this case) for later use.

Ensure an application is deployed using the created PVC, as described in the Deploy an Application documentation.

Using an Existing Snapshot Controller

Replicated PV Mayastor runs a csi-snapshot-controller container by default. A cluster should run only one snapshot controller, so if one is already managed at the cluster level, disable the bundled one during installation or upgrade.

--set openebs.mayastor.csi.controller.snapshotController.enabled=false

Creating a Volume Snapshot

Snapshots can be created either with an active application or directly from the PVC.

1. Define the VolumeSnapshotClass.

   Copy

   Create a Default VolumeSnapshotClass for Replicated PV Mayastor

   cat <<EOF | kubectl create -f -
   kind: VolumeSnapshotClass
   apiVersion: snapshot.storage.k8s.io/v1
   metadata:
     name: csi-mayastor-snapshotclass
     annotations:
       snapshot.storage.kubernetes.io/is-default-class: "true"
   driver: io.openebs.csi-mayastor
   deletionPolicy: Delete
   EOF

   Alternatively, apply using a YAML file:

   Copy

   Apply the VolumeSnapshotClass Definition

   kubectl apply -f class.yaml

   Copy

   Sample Output

   volumesnapshotclass.snapshot.storage.k8s.io/csi-mayastor-snapshotclass created

2. Create the Snapshot.

   Copy

   Create a VolumeSnapshot from an Existing PVC

   cat <<EOF | kubectl create -f -
   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: mayastor-pvc-snap
   spec:
     volumeSnapshotClassName: csi-mayastor-snapshotclass
     source:
       persistentVolumeClaimName: ms-volume-claim   
   EOF

   Copy

   Apply the VolumeSnapshot Configuration

   kubectl apply -f snapshot.yaml

   Copy

   Sample Output

   volumesnapshot.snapshot.storage.k8s.io/mayastor-pvc-snap created

   Snapshots on thick-provisioned volumes are automatically converted to thin-provisioned volumes.

Listing Snapshots

Use the following commands to view snapshot and snapshot content details.

kubectl get volumesnapshot

NAME                READYTOUSE   SOURCEPVC         SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS                SNAPSHOTCONTENT                                     CREATIONTIME      AGE
mayastor-pvc-snap   true         ms-volume-claim                           1Gi           csi-mayastor-snapshotclass   snapcontent-174d9cd9-dfb2-4e53-9b56-0f3f783518df    57s               57s

kubectl get volumesnapshotcontent

NAME                                               READYTOUSE   RESTORESIZE   DELETIONPOLICY   DRIVER                    VOLUMESNAPSHOTCLASS          VOLUMESNAPSHOT      VOLUMESNAPSHOTNAMESPACE   AGE
snapcontent-174d9cd9-dfb2-4e53-9b56-0f3f783518df   true         1073741824    Delete           io.openebs.csi-mayastor   csi-mayastor-snapshotclass   mayastor-pvc-snap   default                   87s

Deleting a Snapshot

Use the following commands to delete a snapshot.

kubectl delete volumesnapshot mayastor-pvc-snap

volumesnapshot.snapshot.storage.k8s.io "mayastor-pvc-snap" deleted

Filesystem Consistent Snapshots

DataCore Puls8 supports filesystem-consistent snapshots by default. This ensures data integrity by quiescing active I/O operations using the FIFREEZE and FITHAW ioctls during snapshot creation. If the filesystem quiescing process fails, the entire snapshot operation is retried automatically by the Mayastor CSI controller.

To disable filesystem quiescing, modify the VolumeSnapshotClass as follows:

kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1
metadata:
  name: csi-mayastor-snapshotclass
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: "true"
parameters:
  quiesceFs: none
driver: io.openebs.csi-mayastor
deletionPolicy: Delete

Snapshot Capacity and Commitment Considerations

Replicated PV Mayastor enforces capacity admission controls using commitment thresholds to ensure safe and reliable operation of storage pools. These commitment limits apply broadly to volume creation, replica placement, and snapshot operations, and help prevent pool over-allocation and potential data integrity risks.

Understanding these commitment controls is important for capacity planning and for avoiding failures during volume provisioning, replica creation, or snapshot-based backup operations.

Commitment Controls

Replicated PV Mayastor uses the following commitment thresholds to regulate storage allocation:

Pool Commitment

Pool commitment defines the maximum allowed logical overcommitment of a DiskPool when thin provisioning is enabled.

This allows logical allocation to exceed physical capacity within safe limits. For example, if a pool has 10 GiB physical capacity and the pool commitment is configured as 250%, the pool can support up to 25 GiB of logically provisioned storage, subject to other commitment constraints.

If the pool reaches its configured commitment limit, further operations may be blocked, including:

• Volume creation
• Replica creation
• Snapshot creation

This behavior prevents unsafe over-allocation of storage resources.

Volume Commitment

Volume commitment defines the minimum required free space on each replica pool when creating replicas for an existing volume. This ensures that sufficient space is available to safely accommodate replica data and future write operations.

If the required free space is not available on a replica pool, replica creation fails and the volume cannot be provisioned on that pool.

Initial Volume Commitment

Initial volume commitment applies when creating replicas for a new volume. It enforces the same minimum free space requirement during initial volume provisioning to ensure reliable replica placement.

Snapshot Commitment

Snapshot commitment defines the minimum required free space on each replica pool when creating snapshots of an existing volume. This ensures that sufficient space is available to support copy-on-write operations after the snapshot is created.

If any replica pool does not meet the snapshot commitment requirement, snapshot creation fails and any dependent backup operation cannot proceed.

Snapshot Commitment Behavior

VolumeSnapshots require sufficient free space on each replica pool relative to the volume size.

For example:

• Snapshot commitment: 40%
• Volume size: 100 GiB
• Required free space per replica pool: 40 GiB

If any replica pool has less than the required free space, snapshot creation fails.

This check ensures reliable snapshot operation and protects against capacity exhaustion during snapshot lifecycle operations.

Pool Commitment Impact on Snapshots and Thick-Provisioned Volumes

Pool commitment can also affect snapshot creation, particularly for thick-provisioned volumes.

When a snapshot is taken of a thick-provisioned volume:

• The snapshot’s logical size equals the volume size.
• The snapshot initially references existing data using copy-on-write semantics.
• As part of snapshot creation, the volume is internally converted to thin provisioning.

Due to this conversion, the pool must account for potential copy-on-write growth, increasing the pool’s committed capacity by an amount equal to the volume size. If this increase causes the pool to reach its commitment limit, snapshot creation may fail even when sufficient physical free space appears to be available.

This behavior ensures safe storage allocation and prevents capacity exhaustion scenarios.

Example: Snapshot Creation with Commitment Constraints

The following example illustrates how snapshot commitment affects snapshot creation when replica pool capacity is constrained. In this example, volumes are thick-provisioned and snapshot commitment is configured to 40%.

Snapshot creation succeeds only when all replica pools meet the snapshot commitment requirement. If any replica pool fails the check, the snapshot and any dependent backup operation fails.

Default Commitment Values and Configuration

Replicated PV Mayastor uses configurable Helm parameters to enforce commitment controls:

• Pool Commitment
  • --set openebs.mayastor.agents.core.capacity.thin.poolCommitment
  • Default: 250%
  • Defines the maximum logical overcommitment allowed per DiskPool.
• Volume Commitment
  • --set openebs.mayastor.agents.core.capacity.thin.volumeCommitment
  • Default: 40%
  • Defines the minimum free space required to create replicas for existing volumes.
• Initial Volume Commitment
  • --set openebs.mayastor.agents.core.capacity.thin.volumeCommitmentInitial
  • Default: 40%
  • Defines the minimum free space required when provisioning new volumes.
• Snapshot Commitment
  • --set openebs.mayastor.agents.core.capacity.thin.snapshotCommitment
  • Default: 40%
  • Defines the minimum free space required on each replica pool to allow snapshot creation.

The default values are suitable for most environments and provide a balanced trade-off between capacity utilization and operational safety. In typical deployments, these values do not require modification.

However, environments with large volumes, frequent snapshots, or aggressive thin provisioning may require tuning these parameters during installation or upgrade. Any changes should be accompanied by careful capacity planning and continuous monitoring of DiskPool utilization to ensure reliable snapshot creation.

A snapshot preserves the label layout version of the volume it is taken from, and a volume restored from that snapshot inherits the same version. When planning pool capacity, account for the per-replica metadata and alignment overhead of each restored volume in addition to the snapshot's own space requirement. Refer to Creating a DiskPool.

Volume Snapshots for Local PV LVM

This section explains how to create and manage volume snapshots for Local PV LVM volumes. Snapshots are created through the standard Kubernetes VolumeSnapshot resources, and the driver applies two settings that differ from the defaults of the lvcreate command:

• Snapshots created by the driver are read-only, rather than the read-write snapshots that lvcreate creates by default.
• The size of the snapshot is set to the size of the origin volume, unless a snapSize parameter is specified in the VolumeSnapshotClass.

Snapshot support requires the dm-snapshot kernel module to be loaded on the node.

Volume restore is supported only for thin snapshots. A restore from a snapshot of a thick-provisioned volume is not supported. Refer to the Restore a Volume from a Snapshot documentation for the complete list of requirements.

Using an Existing Snapshot Controller

Local PV LVM runs a snapshot-controller container by default. A cluster should run only one snapshot controller, so if one is already managed at the cluster level, disable the bundled one during installation or upgrade.

--set openebs.lvm-localpv.lvmController.snapshotController.enabled=false

VolumeSnapshotClass Without the snapSize Parameter

When the VolumeSnapshotClass does not specify snapSize, the type of the snapshot follows the type of the source volume: a thin volume produces a thin snapshot, and a thick volume produces a thick snapshot. For a thick volume, the driver reserves a size equal to the volume for the snapshot.

kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1
metadata:
  name: lvmpv-snapclass
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: "true"
driver: local.csi.openebs.io
deletionPolicy: Delete

VolumeSnapshotClass With the snapSize Parameter

Use the snapSize parameter to configure the size of the snapshot. When snapSize is specified, the driver creates a thick snapshot of that size, whether the source volume is thin or thick provisioned. The parameter accepts either of the following:

• A percentage, written with a trailing %, for example 50%. The value must be between 1 and 100, and it is applied as a percentage of the capacity of the origin volume. A value outside this range is rejected and the snapshot is not created.
• An absolute size, written as a quantity such as 10G or 500Mi. The value must be greater than 0.

If an absolute snapSize is larger than the origin volume, the driver reduces it to the size of the origin volume. The snapshot is created successfully, so the resulting snapshot can be smaller than the value set in the VolumeSnapshotClass.

kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1
metadata:
  name: lvmpv-snapclass
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: "true"
driver: local.csi.openebs.io
deletionPolicy: Delete
parameters:
  snapSize: 50%

kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1
metadata:
  name: lvmpv-snapclass
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: "true"
driver: local.csi.openebs.io
deletionPolicy: Delete
parameters:
  snapSize: 10G

Creating a Volume Snapshot

1. Apply the VolumeSnapshotClass.

   Copy

   Apply the VolumeSnapshotClass Definition

   kubectl apply -f snapshotclass.yaml

   Copy

   Sample Output

   volumesnapshotclass.snapshot.storage.k8s.io/lvmpv-snapclass created

2. Identify the PVC for which the snapshot is to be created.

   Copy

   Identify PVC

   kubectl get pvc

   Copy

   Sample Output

   NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
   csi-lvmpvc   Bound    pvc-c7f42430-f2bb-4459-9182-f76b8896c532   4Gi        RWO            puls8-lvm       53s

3. Create the snapshot using the VolumeSnapshotClass for the selected PVC.

   Copy

   Create a VolumeSnapshot

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: lvm-localpv-snap
   spec:
     volumeSnapshotClassName: lvmpv-snapclass
     source:
       persistentVolumeClaimName: csi-lvmpvc

   Copy

   Apply the VolumeSnapshot Configuration

   kubectl apply -f lvmsnapshot.yaml

   Copy

   Sample Output

   volumesnapshot.snapshot.storage.k8s.io/lvm-localpv-snap created

   Create the snapshot in the same namespace as the PVC. Ensure readyToUse: true before using the snapshot.

Listing Snapshots

kubectl get volumesnapshot

NAME               READYTOUSE   SOURCEPVC    RESTORESIZE   SNAPSHOTCLASS     SNAPSHOTCONTENT                                    CREATIONTIME   AGE
lvm-localpv-snap   true         csi-lvmpvc   0             lvmpv-snapclass   snapcontent-f771db56-1cef-43d1-ac88-d0e789d4b718   15s            15s

Verifying the LVMSnapshot CR

Check the Local PV LVM resource for the created snapshot and confirm that the state is Ready.

kubectl get lvmsnapshot -n puls8

NAME                                            AGE
snapshot-f771db56-1cef-43d1-ac88-d0e789d4b718   3m12s

kubectl get lvmsnapshot -n puls8 -o yaml

apiVersion: local.openebs.io/v1alpha1
kind: LVMSnapshot
metadata:
  name: snapshot-f771db56-1cef-43d1-ac88-d0e789d4b718
  namespace: puls8
  labels:
    kubernetes.io/nodename: worker-node-1
    openebs.io/persistent-volume: pvc-7d27935e-c72a-4f6b-8314-96ee600e01e8
spec:
  capacity: "4294967296"
  ownerNodeID: worker-node-1
  shared: "no"
  volGroup: lvmvg
status:
  state: Ready

Node-Level Validation

To confirm that the snapshot has been created, log in to the node and list the LVM logical volumes. The snapshot is listed with the origin volume in the Origin column.

lvs

LV                                       VG    Attr       LSize Origin                                   Data%
f771db56-1cef-43d1-ac88-d0e789d4b718     lvmvg sri-a-s--- 4.00g pvc-7d27935e-c72a-4f6b-8314-96ee600e01e8 0.00
pvc-7d27935e-c72a-4f6b-8314-96ee600e01e8 lvmvg owi-aos--- 4.00g

Volume Snapshots for Local PV ZFS

This section explains the process for creating and managing volume snapshots for Local PV ZFS volumes. ZFS snapshots are file-system level, point-in-time copies that support clone and backup workflows in Kubernetes environments.

Using an Existing Snapshot Controller

Local PV ZFS runs a snapshot-controller container by default. A cluster should run only one snapshot controller, so if one is already managed at the cluster level, disable the bundled one during installation or upgrade.

--set openebs.zfs-localpv.zfsController.snapshotController.enabled=false

Creating a Volume Snapshot

1. Define the VolumeSnapshotClass.

   Copy

   Create a Default VolumeSnapshotClass for Local PV ZFS

   $ cat snapshotclass.yaml
   kind: VolumeSnapshotClass
   apiVersion: snapshot.storage.k8s.io/v1
   metadata:
     name: zfspv-snapclass
     annotations:
       snapshot.storage.kubernetes.io/is-default-class: "true"
   driver: zfs.csi.openebs.io
   deletionPolicy: Delete

   Alternatively, apply using a YAML file:

   Copy

   Apply the VolumeSnapshotClass Definition

   kubectl apply -f class.yaml

   Copy

   Sample Output

   volumesnapshotclass.snapshot.storage.k8s.io/zfspv-snapclass created

2. Identify the PVC.

   Copy

   Identify PVC

   kubectl get pvc

   Copy

   Sample Output

   NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
   csi-zfspv   Bound    pvc-73402f6e-d054-4ec2-95a4-eb8452724afb   4Gi        RWO            openebs-zfspv   2m35s

3. Create the Snapshot.

   Copy

   Create a VolumeSnapshot

   $ cat snapshot.yaml
   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: zfspv-snap
   spec:
     volumeSnapshotClassName: zfspv-snapclass
     source:
       persistentVolumeClaimName: csi-zfspv

   Copy

   Apply the VolumeSnapshot Configuration

   kubectl apply -f snapshot.yaml

   Copy

   Sample Output

   volumesnapshot.snapshot.storage.k8s.io/zfspv-snap created

   Create the snapshot in the same namespace as the PVC. Ensure readyToUse: true before using the snapshot.

Listing Snapshots

Use the following commands to view snapshot and snapshot content details.

kubectl get volumesnapshot.snapshot

NAME         READYTOUSE   SOURCEPVC   SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS     SNAPSHOTCONTENT                                    CREATIONTIME   AGE
zfspv-snap   true         csi-zfspv   -                       4Gi           zfspv-snapclass   snapcontent-b747cc44-6845-4e72-b0a9-4fb65858e013   106s           106s

kubectl get volumesnapshot.snapshot zfspv-snap -o yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"snapshot.storage.k8s.io/v1","kind":
      "VolumeSnapshot","metadata":{"annotations":{},"name":
      "zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}}
  creationTimestamp: "2020-02-25T08:25:51Z"
  finalizers:
  - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
  - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  generation: 1
  name: zfspv-snap
  namespace: puls8
  resourceVersion: "447494"
  selfLink: /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/zfspv-snap
  uid: 3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
spec:
  source:
    persistentVolumeClaimName: csi-zfspv
  volumeSnapshotClassName: zfspv-snapclass
status:
  boundVolumeSnapshotContentName: snapcontent-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
  creationTime: "2020-02-25T08:25:51Z"
  readyToUse: true
  restoreSize: "0"

Verifying Local PV ZFS Snapshot CR

Check the custom resource created by the ZFS driver.

kubectl get zfssnap -n puls8

NAME                                            AGE
snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd   3m32s

kubectl get zfssnap snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd -n puls8 -o yaml

apiVersion: openebs.io/v1alpha1
kind: ZFSSnapshot
metadata:
  creationTimestamp: "2020-02-25T08:25:51Z"
  finalizers:
  - zfs.openebs.io/finalizer
  generation: 2
  labels:
    kubernetes.io/nodename: e2e1-node2
    openebs.io/persistent-volume: pvc-73402f6e-d054-4ec2-95a4-eb8452724afb
  name: snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
  namespace: puls8
  resourceVersion: "447328"
  selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
  uid: 6142492c-3785-498f-aa4a-569ec6c0e2b8
spec:
  capacity: "4294967296"
  fsType: zfs
  ownerNodeID: e2e1-node2
  poolName: test-pool
  volumeType: DATASET
status:
  state: Ready

Node-Level Validation

Validate snapshot presence directly on the node.

zfs list -t all

NAME                                                                                               USED  AVAIL  REFER  MOUNTPOINT
test-pool                                                                                          818K  9.63G    24K  /test-pool
test-pool/pvc-73402f6e-d054-4ec2-95a4-eb8452724afb                                                  24K  4.00G    24K  /var/lib/kubelet/pods/3862895a-8a67-446e-80f7-f3c18881e391/volumes/kubernetes.io~csi/pvc-73402f6e-d054-4ec2-95a4-eb8452724afb/mount
test-pool/pvc-73402f6e-d054-4ec2-95a4-eb8452724afb@snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd     0B      -    24K  -

Benefits of Volume Snapshots

• Enables point-in-time backup for critical applications.
• Facilitates fast and reliable disaster recovery.
• Minimizes downtime by enabling quick volume restores.
• Simplifies data migration across environments or clusters.

Learn More

• Snapshot Restore
• Backup and Restore
• Data Encryption