Operation Modes

Applicable to both Classic and Federated modes

Portworx Backup supports two operation modes that define how the backup server works with application clusters and manages backup operations:

• Classic mode — the traditional setup where the Portworx Backup server directly connects to application clusters and backup locations.
• Federated mode (also referred to as Managed Service Provider mode or Workload Identity mode) — a secret-less, decentralized setup designed for large-scale or service provider environments. Cloud credentials are never stored on the Portworx Backup server. Instead, each cluster authenticates directly to the backup location using Workload Identity (such as Azure Managed Identity), and Stork handles all backup operations locally.

Choosing the right mode depends on your organizational requirements for security, network topology, and cluster scale.

Classic mode

In Classic mode, the Portworx Backup server directly connects to all application clusters and backup locations. This is the default mode and works well for most standard deployments.

Functioning mechanism:

The following mechanisms apply to Classic mode:

• The Portworx Backup server stores cloud credentials centrally and uses them to access backup locations (such as S3, Azure Blob, and GCS).
• The Portworx Backup server manages backup operations, and Stork on each cluster handles the tasks locally.
• Clusters can be added manually using a kubeconfig or automatically discovered (for AWS EKS).
• The Portworx Backup server requires direct network access to all application clusters.

Deployment scenarios:

Classic mode is best suited for the following deployment scenarios:

• Standard cloud (AWS, Azure, GCP) or on-premises deployments
• Environments where centralized credential management is acceptable
• Setups with a small to moderate number of clusters

Federated mode

Federated mode is designed for service providers and managed platforms environments where each cluster works independently and manages its own backup operations.

In this mode, the Portworx Backup server sends instructions to each cluster but does not directly access the backup location or cluster credentials. Stork on each cluster performs all backup and restore tasks autonomously using Workload Identity, without requiring the Portworx Backup server to have direct access to the backup location.

Functioning mechanism:

The following mechanisms apply to Federated mode:

• The Portworx Backup server sends instructions to application clusters.
• Stork on each cluster handles all backup-related tasks locally, including backup creation, deletion, sync, and validation.
• Cloud credentials are not stored centrally. Each cluster uses workload identity (for example, Azure Managed Identity) to connect directly to the backup location (such as Azure Blob Storage).
• Only object storage is supported. NFS backup locations are not supported in Federated mode.
• Gardener shoot clusters are discovered and added automatically. Other clusters can be added manually using a kubeconfig.
• Backup location validation is performed locally on each cluster by Stork.

Deployment scenarios:

Federated mode is best suited for the following deployment scenarios:

• Service providers managing many clusters (for example, Gardener shoot clusters)
• Organizations with strict security requirements (no centralized credentials)
• Large-scale, multi-cluster deployments

For information on specifications, requirements, and constraints specific to Federated mode, see Federated Mode Specifications.

Operation modes feature comparison

The following table summarizes the key differences between Classic mode and Federated mode:

Feature	Classic mode	Federated mode
Backup location access	Portworx Backup server accesses backup locations directly using centrally stored cloud credentials	Each application cluster accesses backup locations directly using workload identity (for example, Azure Managed Identity); the Portworx Backup server does not access backup locations
Backup deletion	Managed by Portworx Backup server	Managed by Stork locally on the application cluster
Backup sync	Performed automatically and periodically by the Portworx Backup server	Backup sync is initiated when you enable the sync option and assign at least one cluster (with Workload Identity configured) to the backup location during backup location creation. For more information, see Add a backup location in Federated mode. The initial sync occurs after this configuration. Subsequent sync operations are not periodic and must be triggered manually using the Portworx Backup UI, CLI, or API. For more information, see Sync Backups from a backup location. Stork on each cluster performs the sync using Workload Identity.
Backup location validation	Performed by Portworx Backup server	Performed by Stork locally on the application cluster
Cloud credentials	Stored centrally on Portworx Backup server	Never stored centrally; uses workload identity mechanisms (for example, Azure Managed Identity) on each cluster
Cluster onboarding	Select Kubernetes provider (Azure AKS, AWS EKS, GCP, Rancher, etc.), then provide credentials or kubeconfig	No provider selection — Gardener shoot clusters are discovered through the Gardener discovery config or provide kubeconfig directly.
Portworx Backup server connectivity	Requires direct network access to cluster API servers	Requires direct network access to cluster API servers to send instructions. The Portworx Backup server does not access backup locations directly.
Kubernetes platform	Any Kubernetes distribution	Gardener Kubernetes (Garden Linux on Azure) is the primary supported platform. Other Kubernetes clusters (including non-Gardener Gardener shoot clusters) can be added manually using a kubeconfig.
Secret management	Object store access credentials are stored centrally on the Portworx Backup server	Secret-less; no object store access credentials are stored centrally. Each application cluster uses Workload Identity (for example, Azure Managed Identity) to access the backup location directly.
Installation Helm flag	Default (no flag needed)	Required; set via the Portworx Central Spec Generator. For details, see Install Portworx Backup in Federated Mode.
Backup location	Azure, GCP, AWS S3, NFS	Azure Blob Storage only

Next steps

• To install Portworx Backup in Federated mode, see Install Portworx Backup in Federated mode.
• To onboard Gardener shoot clusters in Federated mode, see Manage Clusters (Federated mode).
• To configure backup locations in Federated mode, see Configure Backup Locations in Federated mode.