Requirements for Portworx Backup Installation

The Portworx Backup cluster can be any Kubernetes cluster where you deploy Portworx Backup. The minimum supported size for a Portworx Backup cluster is three worker nodes.
Ensure that you review the compatibility and interoperability matrices to identify supported versions of Portworx Backup, Stork, Portworx Enterprise, and other components.

To install Portworx Backup, each worker node must meet the requirements listed in this section.

Hardware requirements

Hardware Requirements
Up to 2,000 backups
CPU	4 CPU cores minimum per node (8 recommended)
RAM	4 GB per node (8 GB recommended)
Storage space required for PVC creation	506 GB (In Total)
2,000 to 10,000 backups
CPU	8 CPU cores per node
RAM	8 GB per node
Storage space required for PVC creation	506 GB (In Total)
10,000 to 15,000 backups
CPU	8 CPU cores per node
RAM	16 GB per node
Storage space required for PVC creation	506 GB (In Total)
Up to 75,000 backups
CPU	32 CPU cores per node
RAM	32 GB per node
Storage space required for PVC creation	506 GB (In Total)

note

You can change the Prometheus PVC size from 5 GB (default size) to 10 GB or more based on your needs.

Software requirements

2.11.0

Software requirements
Operating System	x86-64 based Linux distros supported by your storage provider RHEL: PXB supports other variants like OpenShift distros but not Vanilla Kubernetes.
On-premises Kubernetes	Vanilla: 1.34.x, 1.33.x, 1.32.x Red Hat OpenShift: 4.20.x, 4.19.x, 4.18.x RKE2 with Rancher (v2.12.3) with v1.33.x, 1.32.x, 1.31.x TKGi: 1.30.7 TKGs: v1.33.3+vmware.1-fips Charmed Kubernetes: 1.33.x, 1.32.x
Managed Kubernetes	AKS: 1.34.2, 1.33.6 ARO: 4.19.x, 4.18.x Anthos: 1.33.5-gke.90, 1.32.x EKS: 1.34.x, 1.33.x, 1.32.x IKS: 1.34.x, 1.33.x GKE: 1.34.x, 1.33.x, 1.32.x ROKS: 4.20.x, 4.19.x ROSA: 4.20.x, 4.19.17
Prometheus	2.35.0
Prometheus Operator	0.87.1
AlertManager	0.30.0 0.28.0 0.27.0 0.26.0
Kubevirt	1.5.0 to 1.0.0
Stork	26.2.0 25.5.0 25.6.0 25.4.1
Portworx	3.5.2 3.5.1 3.5.0 3.4.2 3.4.1 3.4.0.1 3.4.0 3.3.1.3 3.2.3 3.2.2.1 At least 50 GB of free space on the /root file system nodes where Portworx is going to be installed
A block-based provisioner	At least 307 GB of free space to host the PVCs deployed by databases used by Portworx Backup
External Auth Providers	External OIDC and LDAP based Auth providers
FlashArray	6.8.6 6.6.10 6.6.8 6.5.8
FlashBlade	4.5.7 4.4.2

note

• If you are using an external authorization provider, you must use certificates signed by a trusted certificate authority.
• Make sure helm is installed on the client machine: Helm

note

If you are planning to install or upgrade Stork in an air-gapped environment, you must also pull the kopiaexecutor and nfsexecutor images for your Stork version and push them to your custom image registry. For the full list of versioned images, see Install Stork in air-gapped environments.

Network requirements

The minimum supported size for the Portworx Backup cluster is three worker nodes. Each node must meet the following network requirements:

Network Requirements
Network connectivity	Bandwidth: 10 Gbps recommended      (1 Gbps minimum)

note

To install Portworx Backup, ensure that the Kubernetes cluster where you are planning to deploy Portworx Backup and the application clusters you associate with PXB are on IPv4 internet protocol. You can neither install Portworx Backup on an IPv6 enabled Kubernetes cluster nor add IPv6-enabled application clusters to Portworx Backup.

Network port requirements

The following table outlines the ports that need to be enabled on Portworx Backup cluster:

Network Port Requirements
Service	Source Interface	Port	Protocol	Flow Direction	Description
Portworx Central UI	data	6443	TCP	Unidirectional	To talk to client Kubernetes cluster
Portworx Backup	data	6443	TCP	Bidirectional	To talk to client Kubernetes cluster
	management	443	TCP	Bidirectional	To talk to S3 endpoint
	data	111	TCP and UDP	Bidirectional	For NFS server access
	management	2049	TCP and UDP	Bidirectional	For NFS server access
License server	data	7070	TCP	Unidirectional	For communication between License server and Portworx clusters. Traffic source is Portworx cluster, target is license server.
Keycloak	data	8080	TCP	Unidirectional	To talk to external Keycloak/OIDC
	management	8443	TCP	Unidirectional	To talk to external Keycloak/OIDC

KDMP backup requirements

If you need to initiate KDMP or cross-cloud backups, ensure that you allocate additional buffer storage that is double the size of the original Persistent Volume Claim (PVC) in your application cluster. This buffer ensures that there is sufficient storage allocation for data changes, snapshots, or temporary data generated during the backup process.

Prometheus requirements

If you have your own Prometheus installed cluster-wide, ensure that it does not reconcile with the Portworx Backup Prometheus in <pxb-namespace> namespace.

When Prometheus and Alertmanager are in CrashLoopBackOff state, ensure that the global or cluster wide Prometheus Operator does not interfere with the Prometheus and Alertmanager instances in <pxb-namespace> namespace. If so, modify the cluster-wide Prometheus operator to exclude the namespace where the Portworx Backup Prometheus stack is installed.

Add the following entry under spec.template.spec.containers[0].args in the cluster-wide Prometheus Operator spec to resolve conflicts if any:

--deny-namespaces=<pxb-namespace>

Alternatively, you can also set the scope of the cluster-wide Prometheus to a defined namespace using the below parameter:

--namespaces=<cluster-wide-prometheus-installed-namespace>

MongoDB requirements

For upgrades from Portworx Backup 2.8.4 or earlier

In Portworx Backup 2.8.4 and earlier, MongoDB could continue running even if only 1 or 2 of the 3 replica set pods were available. Starting with Portworx Backup 2.9.0, all 3 MongoDB replica set pods must be scheduled, DNS-resolvable, and reachable before Portworx Backup can start.

If you are upgrading from Portworx Backup 2.8.4 or earlier, verify the following before starting the upgrade:

• All 3 MongoDB pods can be scheduled on available nodes (verify node capacity and resource quotas).
• DNS resolution works correctly for all MongoDB pod hostnames within the cluster.
• Network policies or security groups allow pod-to-pod communication on the MongoDB replication port (27017).
• Resolve any existing MongoDB pod issues (for example, Pending or CrashLoopBackOff) before upgrading.

Impact if not addressed: If fewer than 3 MongoDB pods are reachable after the upgrade, Portworx Backup will not start and will remain unavailable until all 3 pods become healthy.

Starting with Portworx Backup 2.9.0, MongoDB requires all 3 replica set pods to be fully operational during startup. Specifically:

• All 3 replica set pods must be running and DNS-resolvable.
• If the primary pod becomes unavailable (for example, after a node reboot), MongoDB waits for all replica set members to become reachable before accepting connections.
• Portworx Backup does not start if only 1 or 2 MongoDB pods are available after installation or upgrade.

This behavior helps prevent replica set misconfiguration and ensures stable replica set formation. Before installing or upgrading to Portworx Backup 2.9.0 or later, ensure that your environment has sufficient node capacity and allows proper pod-to-pod communication.

Cloud cluster requirements

The following are the prerequisites for installing Portworx Backup on a cloud cluster:

AKS cluster requirements

You need the following permissions/actions to install Portworx Backup on an AKS cluster:

Permissions	Purpose
Microsoft.Compute/disks/delete	Allows the deletion of managed disks. This is essential for managing storage and cleaning up unused resources.
Microsoft.Compute/disks/write	Grants permission to create or update managed disks. This is crucial for provisioning storage for virtual machines.
Microsoft.Compute/disks/read	Enables reading the properties and metadata of managed disks. Necessary for monitoring and managing disk resources.
Microsoft.Compute/virtualMachines/write	Permits creating or updating virtual machines. This is essential for provisioning and configuring VMs.
Microsoft.Compute/virtualMachines/read	Allows reading the properties and metadata of virtual machines. This is necessary for monitoring and managing VMs.
Microsoft.Network/loadBalancers/read	Enables reading the properties and metadata of load balancers. This is important for managing and monitoring network traffic distribution.
Microsoft.Network/loadBalancers/write	Permits creating or updating load balancers. This is essential for configuring and managing network traffic distribution.
Microsoft.Network/loadBalancers/delete	Allows for the deletion of load balancers. This is crucial for cleaning up and managing network resources.
Microsoft.Network/publicIPAddresses/read	Enables reading the properties and metadata of public IP addresses. This is necessary for managing public-facing network resources.
Microsoft.Network/publicIPAddresses/write	Permits creating or updating public IP addresses. This is essential for provisioning public-facing network resources.
Microsoft.Network/publicIPAddresses/delete	Allows for the deletion of public IP addresses. This is important for managing and cleaning up network resources.
Microsoft.Network/publicIPAddresses/join/action	Grants permission to join public IP addresses to resources. This is crucial for associating public IP addresses with network resources.
Microsoft.Network/loadBalancers/loadBalancingRules/read	Allows reading the properties and metadata of load balancing rules. This is necessary for monitoring and managing load balancer rules.
Microsoft.Network/loadBalancers/probes/read	Enables reading the properties and metadata of load balancer probes. This is important for managing and monitoring load balancer health checks.
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/ networkInterfaces/read	Grants permission to read the properties and metadata of network interfaces attached to VM scale set instances. This is necessary for monitoring and managing network configurations of scale set VMs.
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/ networkInterfaces/ipconfigurations/publicipaddresses/read	Allows reading the properties and metadata of public IP addresses attached to network interfaces of VM scale set instances. This is crucial for managing and monitoring public-facing network configurations.
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/write	Grants permission to create or update virtual machines within a scale set, important for scaling and managing VM instances.
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read	Allows reading the properties and metadata of virtual machines within a scale set, necessary for monitoring and managing VM instances.
Microsoft.Compute/virtualMachineScaleSets/read	Enables reading the properties and metadata of VM scale sets, important for monitoring and managing scale sets.
Microsoft.Network/networkSecurityGroups/read	Enables reading the properties and metadata of network security groups. This is necessary for monitoring and managing network security configurations.
Microsoft.Network/networkSecurityGroups/write	Grants permission to create or update network security groups. This is essential for configuring and managing network security settings.

note

Sometimes creation of an Azure custom role takes at least 20 minutes for the role (with the specified permissions) to reflect in your Azure cluster environment.

Tanzu Kubernetes Grid Service (TKGS) cluster requirements

Tanzu Kubernetes Grid Service (TKGS) administrators can create deployments, StatefulSets, and DaemonSet (privileged pods) in the kube-system and default namespace, but cannot create in other namespaces. For example, Portworx Backup deployment in the central namespace fails, because Tanzu Kubernetes clusters include the default PodSecurityPolicy.

1. Create a namespace:

   kubectl create ns <pxb-namespace>

2. Before you deploy Portworx Backup, for example in the namespace created above, you need to create a role-binding for privileged and restricted workload deployment using the below commands.

   a. If your Kubernetes version is below 1.25, execute the following command :

   kubectl create rolebinding rolebinding-default-privileged-sa-ns_default --namespace=<pxb-namespace> --clusterrole=psp:vmware-system-privileged --group=system:serviceaccounts

   b. If your Kubernetes version is 1.25 and above, run this command:

   kubectl label ns <pxb-namespace> pod-security.kubernetes.io/enforce=privileged

OCP cluster requirements

To install Portworx Backup on OpenShift using the restricted SCC, you must add the service accounts used by Portworx Backup to the restricted SCC.

Run the following oc adm policy add-scc-to-user commands, replacing <YOUR_NAMESPACE> with your namespace:

oc adm policy add-scc-to-user restricted system:serviceaccount:<YOUR_NAMESPACE>:default
oc adm policy add-scc-to-user restricted system:serviceaccount:<YOUR_NAMESPACE>:pxcentral-apiserver
oc adm policy add-scc-to-user restricted system:serviceaccount:<YOUR_NAMESPACE>:px-keycloak-account
oc adm policy add-scc-to-user restricted system:serviceaccount:<YOUR_NAMESPACE>:px-backup-account