Snapshot of FlashBlade PVC

PX-CSI supports snapshot and restore functionality for FlashBlade Direct Access volumes. This page explains how to create on-demand snapshots or use FlashBlade snapshot policies for scheduled snapshots, and how to restore or delete them.

Snapshots on FlashBlade are metadata-based restore points within the same filesystem. Starting from PX-CSI version 26.3.0 (with Purity version 4.8.0 or later), restoring a snapshot creates a new volume rather than overwriting the source filesystem in place.

Prerequisites

Before you begin, ensure the following:

• FlashBlade API version 2.15 or later (Purity 4.5 or later).
• Policy-based snapshots are supported in PX-CSI version 25.8.0 or later.
• A PersistentVolumeClaim (PVC) backed by a FlashBlade storage class with reclaimPolicy set to Retain. See Reclaim policy. For example:

  kind: StorageClass
  apiVersion: storage.k8s.io/v1
  metadata:
     name: <px-fb-direct-access-nfsv4-retain>
  provisioner: pxd.portworx.com
  parameters:
     backend: "pure_file"
     pure_export_rules: "*(rw)"
  mountOptions:
     - nfsvers=4.1
  volumeBindingMode: WaitForFirstConsumer
  allowVolumeExpansion: true
  reclaimPolicy: Retain

Create a snapshot

On-demand snapshots

Follow the steps below to create a snapshot on demand using the Kubernetes VolumeSnapshot API.

1. Create a VolumeSnapshotClass to define how snapshots are handled in your cluster. For FlashBlade Direct Access, set the driver to pxd.portworx.com and specify a deletion policy such as Delete or Retain, depending on your snapshot lifecycle requirements. For more information about deletionPolicy, refer to DeletionPolicy.

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshotClass
   metadata:
     name: <px-csi-fbda-class>
   driver: pxd.portworx.com
   deletionPolicy: Delete

2. Create a VolumeSnapshot to capture the state of your PersistentVolumeClaim using the class defined above:

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: <px-csi-fbda-snapshot>
     namespace: <your-pvc-namespace>  # Must match the PVC's namespace
   spec:
     volumeSnapshotClassName: px-csi-fbda-class
     source:
       persistentVolumeClaimName: <your-pvc-name>

3. Verify snapshot creation:

   kubectl get volumesnapshot <px-csi-fbda-snapshot>
   kubectl describe volumesnapshot <px-csi-fbda-snapshot>

Policy-based scheduled snapshots

PX-CSI supports integration with FlashBlade snapshot policies to automate snapshot creation and retention. In this method, scheduling and cleanup are handled entirely by FlashBlade, not Kubernetes.

A FlashBlade snapshot policy defines when snapshots are taken and how long they are retained. PX-CSI links the PersistentVolumeClaim (PVC) filesystem to an existing FlashBlade policy, allowing FlashBlade to manage snapshots on a schedule.

note

Using a VolumeSnapshotClass with a FlashBlade policy attaches the policy only to the filesystem. It does not apply to Kubernetes-native volume snapshots created through VolumeSnapshot objects.

• Snapshots are created and retained by FlashBlade according to the policy rules.
• These snapshots aren't represented as Kubernetes VolumeSnapshot objects.
• During restore, PX-CSI queries FlashBlade for the latest snapshot created by the policy and restores it to:
  • a new volume if the PX-CSI version is 26.3.0 or later and Purity version is 4.8.0 or later.
  • the same volume in place if the PX-CSI version is 26.2.1 or earlier, or if the PX-CSI version is 26.3.0 or later with a Purity version earlier than 4.8.0 and environment variable ENABLE_FB_INPLACE_RESTORE set to "true" in the StorageCluster.
• PX-CSI does not create, track, or delete individual scheduled snapshots.

Follow the steps below to create policy-based snapshots:

1. Create a FlashBlade snapshot policy:

   1. In the FlashBlade dashboard, go to Settings → Policies → Snapshot Policies.
   2. Select Create Policy.
   3. Define a name, schedule (e.g., hourly/daily), and retention period.
   4. Select Save.

2. Create a VolumeSnapshotClass to define how snapshots are handled in your cluster. For FlashBlade Direct Access, set the driver to pxd.portworx.com and specify a deletion policy such as Delete or Retain, depending on your snapshot lifecycle requirements. For more information about deletionPolicy, refer to DeletionPolicy.

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshotClass
   metadata:
     name: <px-csi-fbda-class>
   driver: pxd.portworx.com
   deletionPolicy: Delete
   parameters:
      policy_name: "<fb-snapshot-policy>"

3. Create a VolumeSnapshot to capture the state of your PersistentVolumeClaim using the class defined above:

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: <px-csi-fbda-snapshot>
     namespace: <your-pvc-namespace>  # Must match the PVC's namespace
   spec:
     volumeSnapshotClassName: <px-csi-fbda-class>
     source:
       persistentVolumeClaimName: <your-pvc-name>

4. Verify snapshot creation:

   kubectl get volumesnapshot <px-csi-fbda-snapshot>
   kubectl describe volumesnapshot <px-csi-fbda-snapshot>

Restore from a snapshot

The way you restore a FlashBlade snapshot depends on your PX-CSI and Purity versions:

• If your PX-CSI version is 26.3.0 or later and your Purity version is 4.8.0 or later, restoring a snapshot creates a new volume by default and leaves the source filesystem unchanged. Follow the Restore to a new volume tab below.
• If your PX-CSI version is 26.3.0 or later but your Purity version is earlier than 4.8.0, restoring to a new volume fails by default, with a message asking you to either upgrade Purity to 4.8.0 or later, or set the ENABLE_FB_INPLACE_RESTORE environment variable to "true" on the StorageCluster. If you set the flag to use in-place restore, follow the In-place restore tab below.
• If your PX-CSI version is 26.2.1 or earlier, restoring a snapshot always overwrites the source filesystem in place. Follow the In-place restore tab below.

Select the tab below that matches your workflow.

Restore to a new volume

When you restore a FlashBlade snapshot, PX-CSI creates a new volume from the snapshot while leaving the source filesystem unchanged.

important

You cannot take snapshots of restored volumes.

To restore a snapshot to a new volume:

1. Create a PVC that uses the snapshot as its data source:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: <restored-pvc-name>
     namespace: <your-pvc-namespace>
   spec:
     storageClassName: <px-fb-direct-access-nfsv4-retain>
     dataSource:
       name: <px-csi-fbda-snapshot>
       kind: VolumeSnapshot
       apiGroup: snapshot.storage.k8s.io
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 5Gi  # Must match the original PVC size

2. Verify that the restored PVC is bound:

   kubectl get pvc <restored-pvc-name>

After you restore a snapshot to a new volume, FlashBlade prevents operations that would affect its source dependencies:

• Delete the source volume: The operation fails with a FailedPrecondition error because the source filesystem is being used as the copy source.
• Delete the snapshot: The operation fails with a FailedPrecondition error because the snapshot is backing the restored volume.
• Restore the snapshot again: The operation fails because FlashBlade supports only one copy volume per source filesystem at a time.

To perform any of these operations, you must first delete the restored PVC.

In-place restore

With in-place restore, restoring a snapshot overwrites the source filesystem with the data from the snapshot.

FlashBlade supports restoring only from the most recent snapshot. To restore from an earlier snapshot, you must first delete all newer snapshots.

To perform an in-place restore:

1. Get the name of the PV bound to the PVC:

   kubectl get pvc <your-pvc-name> -o jsonpath='{.spec.volumeName}'

2. Set the PV reclaim policy to Retain. Skip this step if the reclaim policy is already set to Retain:

   kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

3. Scale down the Deployment that uses the PVC to prevent applications from accessing the volume during the restore.

4. Delete the original PVC:

   kubectl delete pvc <your-pvc-name>

5. Recreate the PVC using the snapshot as its data source:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: <your-pvc-name>
   spec:
     storageClassName: <px-fb-direct-access-nfsv4-retain>
     dataSource:
       name: <px-csi-fbda-snapshot>
       kind: VolumeSnapshot
       apiGroup: snapshot.storage.k8s.io
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 5Gi  # Must match the original PVC size

6. Verify that the PVC is recreated and bound:

   kubectl get pvc <your-pvc-name>
   kubectl describe pvc <your-pvc-name>

7. (Optional) Inspect the restored PV:

   kubectl get pv <persistent-volume> -o yaml

8. Scale up the Deployment.

Delete a snapshot

To delete a snapshot (regardless of method):

1. Delete the VolumeSnapshot object:

   kubectl delete volumesnapshot <px-csi-fbda-snapshot>

2. Verify deletion:

   kubectl get volumesnapshot <px-csi-fbda-snapshot>

If deletionPolicy: Retain is set, you must manually delete the corresponding snapshot on FlashBlade. For policy-based snapshots, the persistent volume claim (PVC) won’t be detached from the policy, and snapshots will continue at the specified interval.

Limitations

• No automatic retention/expiry cleanup.
• Manual cleanup is required if deletionPolicy is Retain.
• PX-CSI does not track or display scheduled snapshots as Kubernetes resources.