Backup and Restore FADA Volumes
Portworx Backup supports backing up and restoring Kubernetes applications that mount PersistentVolumeClaims (PVCs) provisioned with FADA (pure_block) volumes, including FlashArray Direct Access (FADA) LUNs and Pure Storage Cloud Dedicated (PSC Dedicated, formerly Cloud Block Store) Direct Access. Two deployment paths are supported, each with different prerequisites:
- Portworx Enterprise without FA/FB driver enabled — Portworx Enterprise manages FADA volumes directly (the traditional FADA path).
- Portworx Enterprise with FA/FB driver enabled — Portworx Enterprise is deployed with the FlashArray/FlashBlade (FA/FB) driver enabled. For how to enable the FA/FB driver, see Enable FA/FB driver on Portworx Enterprise in the Portworx Enterprise documentation.
In both paths, Portworx Backup protects FADA volumes using native Portworx CloudSnap snapshots (PXD-based) for both block and file system PVC modes. KDMP-based backups are supported for PVCs in file system mode only.
On this page, "FA/FB driver enabled" means the FlashArray/FlashBlade (FA/FB) driver is enabled within Portworx Enterprise, set by pure-csi-integration=true on the StorageCluster (Portworx Enterprise 3.7.0 or later). In this mode, Portworx Enterprise uses CloudSnap for snapshots and offload, including raw block and RWX volumes.
This is different from the general CSI provider support in Portworx Backup, including standalone Portworx CSI. For file system-based volumes, Portworx Backup supports CSI providers through KDMP with volume snapshots, which has been available since Portworx Backup 2.7.0. For more information, see the Feature matrix.
This topic covers FADA (pure_block) volumes, which support native Portworx (PXD) snapshots. FlashArray File (FA Files) (pure_fa_file) volumes do not support native snapshots and are backed up differently. For their prerequisites, supported versions, and step-by-step instructions, see Backup and Restore FA Files Volumes.
Prerequisites
- An application with a FADA volume mounted and running
- FlashArray Purity 6.x or later (Purity 6.6.11 for PSC Dedicated for Azure). Verify the exact minimum Purity version required for FADA Direct Access with your Portworx support team, as requirements may differ by deployment type.
- Portworx installed as a storage provisioner for FlashArray/PSC Dedicated, with a FADA StorageClass and PVC
- When Portworx Enterprise does not have the FA/FB driver enabled:
- Portworx Enterprise 3.4.0 or later
- Stork 25.3.1 or later
- When Portworx Enterprise has the FA/FB driver enabled:
- Portworx Backup 3.1.1 or later
- Stork 26.4.1 or later
- Portworx Enterprise 3.7.0 or later
VolumeAttachmentreconciliation is complete for all FADA PV/PVCs after the FA/FB driver is enabled on the Portworx Enterprise cluster. To verify the reconciliation status, see Verify FA/FB driver enablement.
For reliable cross-cluster restore of FADA volumes on Portworx Enterprise deployments without the FA/FB driver enabled, use Portworx Backup 3.1.1 or later and Stork 26.4.1 or later.
With earlier versions, a cross-cluster FADA restore might leave the restored PVC in the Lost state. The PersistentVolume (PV) is not created, and the application pod remains unschedulable, even though Portworx Backup reports the restore as successful.
When Portworx Enterprise is deployed with the FA/FB driver enabled, Portworx Backup supports the full FADA backup, restore, and delete lifecycle without any additional ConfigMap configuration.
FADA behavior with FA/FB driver enabled on Portworx Enterprise
On Portworx Enterprise clusters with the FA/FB driver enabled, Portworx Backup delivers the following improvements over earlier releases:
- Cluster-wide volume resolution: Backup requests are routed and resolved correctly from any node in the cluster, not only from the node where the FADA volume is attached. This fixes volume-not-found errors that occurred on non-attached nodes in earlier releases.
- Reliable restore destination creation: Restore destination PVCs are created correctly. Earlier releases failed with a
PVC namespace not found in locator labels for restoreerror on this path. - Automatic temp restore PVC cleanup: Temporary PVCs created during restore are automatically deleted after the restore completes or fails.
- Incremental manual and adhoc backups: Manual and adhoc FADA backups upload incrementally. In earlier releases, every manual or adhoc backup uploaded a full cloudsnap (scheduled backups were unaffected), which increased backup time and object-store usage.
Automatic clone PVC cleanup applies to individual backup operations. Temporary clone PVCs can still remain and require manual cleanup in some scenarios, for example, after you delete all backups of a volume, or with immutable (locked) backup locations, where every backup is a full backup. Remove any leftover temporary PVCs manually in these cases.
FADA backup support matrix
| Category | Detail |
|---|---|
| Backup Location | - NFS - S3 - Azure Blob |
| Application cluster | Kubernetes platform with Portworx Enterprise-provisioned FADA volumes. For supported platforms, see Portworx Enterprise with FlashArray. |
| Backup type | - Manual Backup - Scheduled Backup |
| Backup variants | - Portworx Native (PXD-based) PVC Modes: Filesystem, Block - KDMP Backup PVC Mode: Filesystem |
| Restore | - To any PX-installed cluster - Requires pure_block StorageClass |
| Large Resource Restore | - Supported |
| VM Backup Support | - Works if VM mounts FADA volume |
| Object Lock Support | - Supported |
| Parallel Backup Schedules | - Supported |
| Local Snapshot Restore | - Supported |
Backup FADA volumes
Refer to the following topics to back up FADA volumes on various backup locations:
- Manual backup (object store, including S3)
- Cross-cloud backup
- Back up with NFS
- CSI backup with PXD driver
Restore FADA volumes
Refer to the Restore section to restore FADA volume backups.