NKP Persistent Volume Snapshot Behavior

Nutanix CSI Snapshots (Managed)

Snapshot operations for NKP Persistent Volumes should be performed using the Nutanix CSI driver through Kubernetes (e.g., kubectl and VolumeSnapshot objects).

Supported operations include:

• Snapshot create

• Snapshot restore (creates a new PVC from the snapshot)

• Integration with Kubernetes-aware backup solutions

CSI snapshots are managed snapshots. They are tracked by the Nutanix CSI driver and maintain proper change tracking.

When the underlying storage container is backed by FlashArray, these CSI-managed snapshots ultimately translate into native FlashArray snapshots. Snapshot requests are orchestrated by the Nutanix CSI driver through Prism, which then executes the operation on the FlashArray via API.

Unmanaged Snapshots (Prism or FlashArray-Level)

Nutanix Volume Group Snapshots may also be created directly at the:

• Prism Central / Prism Element level

• Everpure FlashArray level

These snapshots operate outside of the Kubernetes CSI control plane and are therefore considered unmanaged from a Kubernetes perspective.

Unmanaged snapshot operations can disrupt change block tracking (CBT). For example, a Volume Group being overwritten by a snapshot in Prism or on the FlashArray will break Nutanix CBT with the Nutanix CSI driver. For more information about Nutanix snapshot behavior on FlashArray, refer to this link.

Unmanaged snapshots may serve as a failsafe recovery mechanism in catastrophic scenarios where CSI-based recovery is unavailable. However, if an unmanaged snapshot is used to restore a Nutanix Volume Group backing a Persistent Volume, CSI change tracking and snapshot lineage cannot be automatically re-established.

In such cases, the recommended approach is to:

1. Provision a new CSI-managed Persistent Volume.

2. Migrate application data to the new volume and remove the unmanaged persistent volume.

3. Resume normal snapshot and backup operations using CSI-managed workflows on the new volume.