Portworx Backup Release Notes
Portworx Backup 3.0.0
June 01, 2026
Refer to these topics before you start the install or upgrade tasks:
Features
Federated Mode Support
Portworx Backup now introduces Federated mode (also referred to as Managed Service Provider mode or Workload Identity mode), a secret-less, decentralized deployment model designed for large-scale and service provider environments. In this mode, the cloud credentials are never stored on the Portworx Backup server. Instead, each application cluster authenticates directly to the backup location using Workload Identity, and Stork handles all backup operations locally. Federated mode requires Stork 26.3.0 or later on each application cluster.
Portworx Backup 3.0.0 supports two modes of operation: Federated mode for Managed Service Providers and large-scale environments, and Classic mode for existing users and non-MSP deployments. You can choose the mode that fits your environment during installation or upgrade. For more information, see Install Portworx Backup in Federated Mode.
Federated Command & Control
In Federated mode, the Portworx Backup server sends instructions to application clusters but does not directly access backup locations or cloud credentials. Stork on each cluster performs all backup and restore tasks autonomously using Workload Identity. Azure Workload Identity for Stork is configured through the StorageCluster (STC) custom resource on each application cluster via the Portworx Operator. For setup instructions, see Install Portworx Backup in Federated Mode. This eliminates the need to deploy a separate Portworx Backup instance per cluster and removes the requirement to manage cloud credentials centrally.
Secret-less Authentication with Workload Identity
Portworx Backup Federated mode uses Azure Managed Identity as the Workload Identity mechanism, enabling secret-less authentication for backup operations on Azure. Instead of storing explicit cloud credentials such as access keys, Workload Identity binds a cloud identity to the Stork service account on each shoot cluster, enabling token-based authentication directly with Azure Blob Storage. Cloud credentials are never stored centrally on the Portworx Backup server. Azure Workload Identity for Stork is configured through the StorageCluster (STC) custom resource via the Portworx Operator. For setup instructions, see Install Portworx Backup in Federated Mode.
Gardener Integration on Azure
Portworx Backup Federated mode supports backup of workloads running on Garden Linux–based Kubernetes shoot clusters managed by Gardener on Azure. Garden Linux is a Debian-based Linux distribution used as the host operating system in Gardener-managed clusters. Portworx Backup connects to the Gardener API server to generate kubeconfigs for shoot cluster access and manage cluster registration without manual configuration. Portworx Backup 3.0.0 supports Gardener-managed Kubernetes clusters running version 1.30.x and later.
Backup Sync Using Stork
In Federated mode, backup sync is handled locally by Stork on each application cluster using Workload Identity. The initial sync runs when the sync option is enabled and a cluster is assigned to the backup location. Subsequent syncs must be triggered manually. For more information, see Synchronize backups from a backup location.
Automatic Shoot Cluster Discovery
Portworx Backup Federated mode integrates with the Gardener API to automatically discover and onboard shoot clusters without requiring manual kubeconfig import or registration. You can also configure Portworx Backup to run periodic discovery cycles that detect new and deleted clusters and update the cluster inventory automatically, eliminating the need for manual onboarding as the Gardener shoot cluster fleet changes.
Automatic Gardener Kubeconfig Token Refresh
Portworx Backup automatically refreshes kubeconfig tokens generated by the Gardener API for shoot clusters. Because Gardener-issued kubeconfigs are valid only for a limited time, expired tokens can interrupt connectivity and backup operations.
To prevent this, Portworx Backup periodically renews the tokens before they expire, ensuring uninterrupted access to onboarded Gardener shoot clusters without requiring manual kubeconfig updates.
Cluster Connectivity Validation with Backup Location
In Federated mode, backup location connectivity is validated locally by Stork on each application cluster using Azure Managed Identity (Workload Identity), rather than centrally by the Portworx Backup server. Each cluster independently verifies access and reports its validation status back to Portworx Backup. For more information, see Validate cluster connectivity to a backup location.
Telemetry Support
Portworx Backup introduces integration with Pure1, a cloud-based management and support platform provided by Everpure. When enabled, Portworx Backup automatically registers with Pure1, then periodically uploads system health metrics, operational logs, and UUIDs of all onboarded application clusters to Pure1, enabling Everpure support teams to proactively monitor cluster health and assist with diagnostics. Telemetry is disabled by default and must be explicitly enabled. It can be enabled or disabled at any time by patching the px-backup-telemetry-config ConfigMap, without requiring a Helm upgrade.
Enhancements
Backup Deletion Status Metrics
Portworx Backup improves backup lifecycle observability by retaining Prometheus metrics after a backup is deleted. Previously, when a backup was deleted, either manually or through a retention policy, its Prometheus metrics were removed immediately, leaving no audit trail for monitoring or compliance workflows.
Starting with this release, backup information metrics such as pxbackup_backup_object_info are retained with status="Deleted" for the duration of the TTL window configured through the pxbackup.backupInfoMetricsBackfillHours Helm parameter. For a complete list of affected metrics, see Backup Information Metrics.
The original terminal status of the backup (for example, Success, Failed, or PartialSuccess) is preserved in the previous_status label, providing a complete audit trail of the backup lifecycle in Prometheus.
Deleted metrics expire automatically after the configured TTL window without additional storage or memory overhead.
Persistent UI Preferences
Portworx Backup now retains user interface preferences across pages and sessions, reducing the need to repeatedly apply the same selections while navigating the web console.
NS/VM tab preference
When you switch between the Namespace (NS) and Virtual Machine (VM) tabs on pages such as Applications, Backups, Restores, Schedules, and Dashboard, your selection is automatically applied across supported pages. The preference is retained across logins.
If no preference is available (for example, during first login or after clearing browser storage), the UI defaults to the NS tab.
Time bracket preference
The selected time bracket for backup and restore filters is now preserved while navigating across:
- Overview tab activity timeline
- Backups tab
- Restores tab
- All Backups page
- Both NS and VM subtabs
The selected time bracket remains available throughout the session and resets to the default value of Last 24 hours after logout.
Fixes
| Issue Number | Description | Severity |
|---|---|---|
| PB-15136 | Issue: Portworx Backup generated a SIGSEGV panic (nil pointer dereference) in InitLicDriverForOrg during server startup when the in-memory license information for an organization was not populated. This occurred when license loading failed, for example, due to a vendor string mismatch where Flexera returned "Usage based" while the code expected "Usage Based". As a result, recreateAllOrgLicenseFromEtcd skipped populating the license state for the affected organization. Later, when InitializeBillingAgent called InitLicDriverForOrg, the missing license information caused a fatal panic.User Impact: Portworx Backup entered a CrashLoopBackOff state after every restart, making the UI inaccessible.Resolution: Added a nil check in InitLicDriverForOrg after the in-memory license lookup. If the license information for an organization is missing, the function now logs a warning and returns a graceful error instead of panicking. Portworx Backup can now start in a degraded but operational state even if license loading fails for individual organizations.Affected Versions: Portworx Backup 2.x releases (all releases prior to 3.0.0) | Critical |
Known Issues
| Issue Number | Description |
|---|---|
| PB-15544 | Issue: In Federated mode, deleting a BackupLocation from Portworx Backup does not remove the corresponding BackupLocation custom resources (CRs) from registered application clusters. Over time, stale BackupLocation CRs may accumulate in the kube-system namespace, especially when clusters are re-registered.Workaround: Manually identify and delete orphaned BackupLocation CRs from the kube-system namespace on each application cluster if cleanup is required. |
| PB-15541 | Issue: In Federated mode, if an application cluster goes offline while a BackupLocation sync operation is in progress, the BackupLocation sync state may remain in InProgress until the cluster becomes reachable again. During this time, further sync or validation operations on the BackupLocation may not proceed.Workaround: Bring the offline cluster back online so that the sync operation can resume and complete. Alternatively, deleting the offline cluster resets the BackupLocation sync state to Failed. |