Portworx Backup Release Notes
Portworx Backup 3.1.0
August 06, 2026
Refer to these topics before you install or upgrade:
Features
Federated Mode: AWS S3 Backup Locations with IRSA
Portworx Backup Federated mode now supports AWS S3 backup locations using IAM Roles for Service Accounts (IRSA). Stork on each EKS or Gardener AWS shoot cluster authenticates directly to S3 using IRSA, without storing cloud credentials centrally on the Portworx Backup server. This extends Federated mode's secretless architecture to AWS, complementing the existing Azure Managed Identity support introduced in Portworx Backup 3.0.0. Requires Portworx Backup 3.1.0, Portworx Enterprise 3.6.2 or later, Stork 26.4.0 or later, and Portworx Operator 26.3.0 or later.
Federated Mode: GCS Backup Locations with GCP Workload Identity
Portworx Backup Federated mode now supports Google Cloud Storage (GCS) backup locations using GCP Workload Identity Federation. Stork on each GKE or Gardener GCP shoot cluster authenticates directly to GCS using GCP Workload Identity, without storing credentials centrally. These GCS backup locations can also be immutable — GCS immutable backup locations are supported in both Classic and Federated modes, as described in the GCS Immutable Backup Locations entry below. Requires Portworx Backup 3.1.0, Portworx Enterprise 3.6.2 or later, Stork 26.4.0 or later, and Portworx Operator 26.3.0 or later.
GCS Immutable Backup Locations
Portworx Backup now supports Google Cloud Storage (GCS) buckets with a bucket-level retention policy as immutable backup locations, in both Classic and Federated modes. GCS enforces immutability through a bucket-level retention policy, preventing backup objects from being deleted or overwritten until their retention period expires. Portworx Backup auto-detects the retention policy on the GCS bucket during backup location validation and applies WORM protection accordingly. Locked retention policies (Bucket Lock) are supported, as are GCS lifecycle management policies for noncurrent version cleanup. For configuration steps, see Add a GCS Immutable Backup Location for Classic mode and Add a backup location in Federated mode for Federated mode. Requires Portworx Backup 3.1.0, Stork 26.4.0 or later, and Portworx Enterprise 3.6.2 or later.
Gardener-Managed Kubernetes on AWS and GCP
Portworx Backup Federated mode extends support to Gardener-managed Kubernetes shoot clusters running on AWS and GCP, including clusters using Garden Linux as the host OS. You can onboard these clusters into Portworx Backup Federated mode and protect their workloads using AWS IRSA (for AWS shoot clusters) or GCP Workload Identity Federation (for GCP shoot clusters) for secretless authentication with backup locations.
Enhancements
Updated Grafana Monitoring Dashboards
The Portworx Backup Grafana monitoring guide has been updated with new dashboards compatible with Grafana 11.x. Three new dashboard templates are now provided: Global Operations Overview (fleet-wide cluster health, backup location status, and operation trends), Namespace / App Protection (per-application backup health and namespace-level failure drilldowns), and VM / KubeVirt Protection (virtual machine backup status and disk health). The previous Portworx Backup Dashboard has been removed from the documentation as it no longer provides meaningful data. If you previously imported the old Portworx_Backup_Overview.json or grafana-dashboard.json dashboards, remove them from Grafana before importing the new templates.
Telemetry Components Now Use nonroot-v2 SCC on OpenShift
On OpenShift, the Security Context Constraint (SCC) for Portworx Backup telemetry components has changed from anyuid to nonroot-v2. The nonroot-v2 SCC permits the specific non-root UIDs that telemetry requires (for example, UID 10001) while blocking root entirely, reducing the security footprint of the telemetry deployment. This change makes it easier for customer security teams to approve the telemetry workload on OpenShift clusters that enforce least-privilege SCC policies.
Custom Annotations on the px-backup Backend Service
A new Helm value, service.pxBackupServiceAnnotations, allows administrators to set custom annotations on the px-backup backend Kubernetes service, which exposes metrics. This is useful for Prometheus annotation-based scraping and other annotation-driven controllers. Annotations configured through this value survive helm upgrade without requiring manual re-annotation after each upgrade, enabling GitOps-compatible workflows. Behavior and template wiring mirror the existing pxBackupUIServiceAnnotations field.
Restrict UI Access by Source IP Range on LoadBalancer Services
Two new Helm values, pxCentralUILoadBalancerSourceRanges and pxBackupUILoadBalancerSourceRanges, allow administrators to restrict access to the PX-Central UI and Portworx Backup UI services when they are exposed through a LoadBalancer. Each value takes a list of source IP ranges (CIDRs); Portworx Backup populates the corresponding Kubernetes service's loadBalancerSourceRanges field so that only clients within the listed ranges can reach the UI through the load balancer. Both values default to an empty list ([]), which does not restrict access. Use them to limit UI exposure to trusted networks (for example, an administrative subnet or corporate VPN) on cloud providers whose load balancers honor loadBalancerSourceRanges.
Searchable Backup Location Selector in Create Backup
The Backup Location field in the Create Backup view now supports inline search and filtering. You can type a keyword to filter backup locations by name (case-insensitive), and a No backup locations found state appears when no locations match. This change improves usability for administrators managing large numbers of backup locations, reducing the risk of selecting the wrong location when scrolling through long lists.
Portworx Backup Web Console Is Private by Default
The default service type for the Portworx Backup and PX-Central web console services (pxBackupUIServiceType and pxCentralUIServiceType) is now ClusterIP, so new installations keep the admin console private — reachable only from within the cluster — by default. Exposing the console externally through a LoadBalancer now requires explicit opt-in. You can choose the exposure model during installation using the Select Admin UI Access Type field in the Portworx Central Spec Generator (Internal Access Only (ClusterIP) or External Access (via Load Balancer)), or by setting the Helm values directly. When you do expose the console through a load balancer, you can also request an internal (private) load balancer and restrict access by source IP range. For details, see Configure Access to Portworx Backup Web Console.
Fixes
| Issue Number | Description | Severity |
|---|---|---|
| PB-16584 | Issue: In Federated mode, Portworx Backup is designed to block backups of volume types that are not supported in Federated mode by setting the portworx.io/federated-mode annotation on the backup custom resource, which Stork checks before proceeding. This annotation was applied only to restore custom resources, not to backup custom resources, so the Federated-mode check evaluated as false for backups and the restriction was never enforced.User Impact: In Federated mode, backups of unsupported volume types were not blocked as intended, allowing such backups to be attempted instead of being rejected up front. Resolution: Portworx Backup now sets the portworx.io/federated-mode annotation on both one-time and scheduled backup custom resources, so Stork correctly enforces the Federated-mode restriction for backups as well as restores.Affected Versions: 3.0.0 | Major |
| PB-15414 | Issue: After deleting a CSI+offload backup on ODF (OpenShift Data Foundation) clusters, local VolumeSnapshotContent (VSC) objects and their associated snapshots were not cleaned up. A race condition caused a version-mismatch error during VSC status update to be silenced, so the cleanup operation returned without retrying, leaving orphaned snapshots on the application cluster. User Impact: Orphaned local VolumeSnapshotContent objects and snapshots accumulated on ODF clusters with each backup deletion, consuming cluster storage and requiring manual cleanup. Resolution: The error from a failed VSC status update during deletion is no longer silenced. The operation now returns the error so the caller can retry, ensuring VSC and snapshot cleanup completes successfully. Affected Versions: Versions prior to 3.1.0 | Major |