Backup and Restore FA Files Volumes

Applicable to Classic mode only

This topic describes how to back up and restore Kubernetes applications that use PersistentVolumeClaims (PVCs) provisioned with FlashArray File (FA Files) volumes, where the associated StorageClass is configured with backend: pure_fa_file.

Unlike FADA (pure_block) volumes, FA Files volumes do not support native (cloudsnap or CSI) snapshots. Portworx Backup therefore protects FA Files volumes using Direct KDMP (also called the generic mechanism), which copies the volume's file system contents to the backup location rather than taking a storage-native snapshot. You select Direct KDMP by enabling the Cross Cloud Backup/Restore option in the Create Backup window. For the underlying concept, see Direct KDMP/generic.

Classic mode only

Because FA Files volumes are protected using Direct KDMP, they are supported in Classic mode only. Direct KDMP (cross-cloud) backups are not available in Federated mode.

Prerequisites

• An application up and running with an FA Files volume (pure_fa_file) mounted to it.
• FA Files volumes provisioned through Portworx with FlashArray CSI integration. This is supported with Portworx Enterprise 3.7.0 or later (with FlashArray CSI integration enabled on the StorageCluster) or with Portworx CSI. For provisioning details and how to create the FA Files StorageClass, see the Portworx FlashArray CSI documentation.
• Stork 26.4.1 or later on the application cluster.
• Portworx Backup 3.1.1 or later.
• An FA Files StorageClass that uses the backend: pure_fa_file parameter. FA Files PVCs are Filesystem volumes with the ReadWriteMany access mode. For the StorageClass definition and how to obtain values such as pure_fa_file_system and pure_nfs_policy, see the Portworx FlashArray CSI documentation.
• A configured backup location (object store or NFS). Direct KDMP supports S3-compatible object stores, Azure Blob Storage, Google Cloud Storage, and NFS shares.
• Sufficient CPU and memory headroom on the application cluster for the KDMP data-mover pods, along with the RBAC permissions for KDMP to create and run these pods in the namespace being backed up. For tuning the data-mover pod resources, see Configure kdmp-config ConfigMap parameters. For the additional buffer storage that generic/KDMP backups require, see Cluster Prerequisites.
• Because FA Files backups use the same cross-cloud (Direct KDMP) path as any other generic backup, they share the cross-cloud prerequisites. In particular, if you use the Linkerd service mesh with mTLS enabled, the namespace being backed up must carry the required Linkerd annotations. See Prerequisites in Create a Cross Cloud Backup and Enable mTLS using Linkerd.

FA Files backup support matrix

Category	Detail
Backup mechanism	Direct KDMP only — enable Cross Cloud Backup/Restore. Native cloudsnap and CSI snapshots are not supported for FA Files volumes.
Backup location	- S3-compatible object stores - Azure Blob Storage - Google Cloud Storage - NFS
Application cluster	Any Kubernetes platform where Portworx provisions FA Files volumes. For provisioning, see the FlashArray documentation for Portworx Enterprise or Portworx CSI.
Backup type	- Manual backup - Scheduled backup
PVC mode	Filesystem (ReadWriteMany)
Restore	To any Portworx-installed cluster that has an FA Files (pure_fa_file) StorageClass available

Back up FA Files volumes

Back up FA Files volumes using Direct KDMP by enabling Cross Cloud Backup/Restore in the Create Backup window:

1. Log in to the Portworx Backup web console.

2. From the left navigation pane, click the Clusters icon, and then select the application cluster that contains the namespace or VM with the FA Files volume you want to back up.

3. Go to the Applications tab, choose the NS or VM tab, and select the namespace(s) or VM(s) to back up.

4. Click Backup.

5. In the Create Backup window, specify the following:

   • Enter name for Backup: provide a name for the backup.

   • Backup location: select the object store or NFS backup location where the backup is stored.

   • Cross Cloud Backup/Restore: enable this toggle. This is required for FA Files volumes — it triggers a Direct KDMP backup and disables the Snapshot Class Mapping option (FA Files volumes do not support snapshot-based backups).

     important

     If you do not enable Cross Cloud Backup/Restore, Portworx Backup attempts a snapshot-based backup, which FA Files volumes do not support. Always enable this option when backing up FA Files volumes.

   • Pre-exec rule and Post-exec rule (optional): to take application-consistent backups, select rules to run before and after the backup — for example, to quiesce (freeze) the application before the backup and unquiesce (thaw) it afterward. FA Files backups support the same pre-exec and post-exec rules as other backups. For more information, see Backup Rules.

   • Backup type: choose whether the backup runs immediately (manual) or on a schedule. For a scheduled backup, select a schedule policy.

6. Click Create.

To confirm the backup, view it in the Clusters > Backups tab of your application cluster and check its status.

For the complete list of fields in the Create Backup window (rules, labels, schedule policies, and parallel backup), see Create a Cross Cloud Backup.

Restore FA Files volumes

note

Portworx Backup does not support restoring static PV/PVCs through the Direct KDMP restore path used by cross-cloud backups. This limitation is specific to the Direct KDMP restore path.

You restore an FA Files backup the same way as any Direct KDMP backup. On the destination cluster, an FA Files (pure_fa_file) StorageClass must be available so that the restored PVCs can be provisioned.

To restore an FA Files backup, follow these steps:

1. Log in to the Portworx Backup web console.
2. From the left navigation pane, click Backups, and locate the FA Files backup you want to restore.
3. Click the options menu (⋮) for the backup and select Restore.
4. Enter a name for the restore, and select the destination cluster and namespace.
5. Choose how the restored PVCs are provisioned:
   • Default (no StorageClass mapping): an FA Files (pure_fa_file) StorageClass with the same name as the source StorageClass must exist on the destination cluster. The restore fails if a StorageClass with that name is not present.
   • StorageClass mapping: to provision the restored PVCs onto a different StorageClass, map the source StorageClass to a destination FA Files (pure_fa_file) StorageClass. With mapping, the destination StorageClass name does not have to match the source — it only needs to be a valid pure_fa_file StorageClass.
6. Complete the remaining restore options and start the restore.

For the full restore procedure and all available options, see Restore.