Portworx Backup Release Notes

Portworx Backup 3.2.0

November 12, 2026

Refer to these topics before you install or upgrade:

• Support Matrix
• Install Portworx Backup
• Upgrade Portworx Backup

End of life notification

License Server UI decoupling: Portworx Backup 3.2.0 decouples the License Server UI from Portworx Backup and Portworx Central. To manage Portworx Enterprise licenses, install a standalone license server, or follow the guide in the lsctl CLI reference. Portworx Backup licenses are not affected. You continue to manage them from the License page in the Portworx Backup web console. For more information, see Configure licensing.

If you installed the license server with Portworx Backup using Helm, the upgrade keeps the license server resources, and no additional steps are needed. If you upgrade using Argo CD, ensure to annotate the license server resouces, for more information see Upgrade Portworx Backup using Argo CD.

Features

• SUSE Virtualization support: Portworx Backup 3.2.0 introduces support for backing up and restoring virtual machines (VMs) running on SUSE Virtualization clusters. For prerequisites and cluster onboarding instructions, see Add SUSE Virtualization clusters. For backup and restore procedures, see Back up and restore VMs.

• IPv6 and dual-stack networking support: Portworx Backup 3.2.0 adds support for IPv6 and dual-stack (IPv4 and IPv6) networking in Classic mode on OpenShift (OCP) and vanilla Kubernetes. Configure your Kubernetes cluster as dual-stack or IPv6-only before installing or upgrading Portworx Backup installation. For supported platform versions, configuration information, and known limitations, see IPv6 and dual-stack networking support.

• Partial Success for VM Restores: When you restore a backup that contains multiple VMs, Portworx Backup now restores and reports the outcome of each VM separately. If some VMs restore successfully while others fail, the restore completes with a Partial Success status and the VMs that restored successfully are available on the destination cluster. In earlier releases, a single failure marked the entire restore as Failed. For details, see Partial Success for VM Restores. Requires Portworx Backup 3.2.0, Portworx Enterprise 3.7.2 or later, and Stork 26.5.0 or later. Applicable to Classic mode only.

• File and Folder Restore for Windows Server VMs: You can now restore specific files or folders from a VM backup to the same VM for KubeVirt VMs running a 64-bit Windows Server operating system, in addition to the existing support for Linux VMs. The QEMU Guest Agent must be installed and running on the VM. For prerequisites, supported versions, and procedure, see Restore specific files and folders from VM backups. Requires Stork 26.5.0 or later for Windows Server VMs.

• MongoDB Master Encryption Key Rotation: Starting with Portworx Backup 3.2.0, you can replace the MongoDB master encryption key (Customer Master Key) during an upgrade. The pre-upgrade health check report shows whether the new key was applied or the existing key was kept. For the procedure and troubleshooting steps, see Rotate the MongoDB master encryption key.

• Backup Schedules Page for Fleet Operators: A new Backup schedules page (Backups > Backup schedules) lists the backup schedules across all clusters in a single view. You can filter schedules by cluster, name, status, owner, backup location, and policy; suspend, resume, or delete schedules individually or in bulk; and share or bookmark filtered views. For details, see Backup schedules. Applicable to both Classic and Federated modes.

Enhancements

• Helm 4.x Support: Portworx Backup 3.2.0 and later support both Helm 3.x and Helm 4.x for installation and upgrade, including Federated mode and Argo CD deployments. Helm 4.x is not supported for deployments on IBM Cloud clusters; use Helm 3.x on those clusters. For details, see Supported Helm versions.

• Snapshot Cleanup for Failed VMs: When a VM in a VM backup fails, Portworx Backup now deletes the Portworx volume snapshots that were already backed up for that failed VM only, within the same backup cycle, so the storage is reclaimed without waiting for the backup to be deleted. Snapshots of VMs that were backed up successfully in the same backup are not affected. In earlier releases, these snapshots accumulated in the backup location until the backup was manually deleted. For details, see Snapshot Cleanup for Failed VMs. Applicable to Classic mode only.

• Restore CR File Retrieval for Large Restores: For large resource restores that end with Partial success or Failed, you can now retrieve the restore Custom Resource (restore CR) JSON file from the Portworx Backup web console or CLI without direct access to the backup location. Portworx Backup provides a temporary download URL for object store backup locations, or the NFS path and mount command for NFS backup locations. The size of the file served is limited by the MAX_RESTORE_CR_DOWNLOAD_SIZE_BYTES parameter (default 1 GiB). For details, see View Detailed Restore Failures for Large Restores. Applicable to Classic mode only.

• PVC Count and Total Volume Size for VMs: The VM tab of the Applications page now displays the number of PVCs attached to each VM (NO OF PVCS) and the total requested volume size (TOTAL VOLUME SIZE). The total volume size reflects the requested capacity of the PVCs, not the amount of data written. For details, see Applications.

• Timezone Selection and Custom Date-Range Filter: The Portworx Backup web console now supports timezone selection for displaying timestamps, with the browser timezone selected by default. Downloaded reports use the selected timezone. The time filter also includes a new Custom option with a two-month calendar for selecting date ranges. These enhancements are available on the Dashboard, All Backups, and cluster Overview, Backups, and Restores pages. For more information, see All Backups.

Deprecations and changes in behavior

• License Server UI removed from Portworx Backup and Portworx Central: Portworx Backup 3.2.0 decouples the License Server UI from Portworx Backup and Portworx Central, and it is no longer available after you upgrade. To manage Portworx Enterprise licenses, install a standalone license server, or use the lsctl CLI. Portworx Backup licenses are not affected. You continue to manage them from the License page in the Portworx Backup web console. For more information, see Configure licensing.

Fixes

Issue Number	Description	Severity
PB-10647	Issue: When you selected a large number of backups (for example, 100 on a page) and deleted them together from the web console, the backups did not move to the Deleting or Delete Pending state at once. They changed state one by one, slowly. User Impact: Backups for which deletion had already been triggered continued to show the Success state and could still be restored, which gave the wrong impression that they were available. Resolution: Portworx Backup now moves all selected backups to the Delete Pending state in a single bulk operation and blocks restores of backups that are pending deletion. The actual deletion continues to run in the background. Affected Versions: 2.7.0 and later	Major
PB-12702	Issue: On OpenShift (OCP) clusters, KDMP backups failed when an application used a custom Security Context Constraint (SCC) and a user ID (UID) other than the default UID of the namespace. The backup job pod ran with the default UID from the namespace range and could not read files owned by the application UID when those files lacked group or other read permissions (for example, -rw------- 1999 1999). User Impact: Backups of affected applications failed because the backup job pod could not access certain files. Users had to modify file permissions before taking the backup. Resolution: The backup job pod now uses the UID and GID of the application pod, allowing it to access and back up the files without modifying their permissions. Affected Versions: Releases earlier than Portworx Backup 3.2.0.	Major
PB-18047	Issue: The Keycloak image (keycloak:26.6.4_v2) shipped with Portworx Backup contained a vulnerability in the keycloak-services library (CVE-2026-18963). User Impact: Deployments using the affected Keycloak image were exposed to the vulnerability. Resolution: Keycloak is upgraded to version 26.8.0. Affected Versions: 3.1.2 and earlier	Major

Known Issues

Issue Number	Description
PB-19211	Issue: During a VM restore with the replace policy set to Delete, if the Stork leader pod terminates unexpectedly while VM resources are being restored, the newly elected leader might delete and recreate PVCs and PVs that were already restored. Because the PVs use the Delete reclaim policy, this can also delete the underlying Portworx volumes. User Impact: The restore might be reported as Success without any warning or error, even though the restored PVCs reference Portworx volumes that no longer exist. As a result, the VM might fail to start or start without its data disks. Workaround: Restore the affected VM again. The new restore creates PVCs and PVs backed by valid Portworx volumes, provided that no further Stork leader failover occurs while the VM resources are being restored.
PB-19559	Issue: When a VM restore partially fails, such as when a PVC quota is exceeded in the destination namespace, the namespace-level status in the restore details might be inaccurate or differ between S3 and NFS backup locations. The affected namespace might display an incorrect count of failed volumes (for example, 1 of 4 instead of 2 of 4), report Success despite containing a failed VM, or be missing from the namespace list. The namespace-level failure reason might also omit the name of the failed VM. This issue affects restores of Portworx (CloudSnap) volumes. User Impact: The issue affects only namespace-level reporting. The overall restore status and individual VM statuses remain accurate and reflect the actual restore outcome. There is no data loss or impact on the restore operation. Workaround: No corrective action is required. Refer to the overall restore status and individual VM statuses to identify failed VMs and determine the reasons for failure.
PWX-59166	Issue: During VM CloudSnap cleanup, some CloudSnaps associated with a VM backup that failed due to a volume backup failure might remain in the backup location, even though their deletion is reported as successful. User Impact: These CloudSnaps are not visible in normal listings and are not removed by subsequent cleanup cycles. They can accumulate and consume storage in the backup location. Workaround: To enable cleanup of failed CloudSnaps, run the following command on the application cluster, replacing <hours> with the cleanup threshold in hours: pxctl cluster options update --cloudsnap-cleanup-failed-hours <hours>