Upgrade Portworx Backup

Portworx Backup supports upgrades to version n from versions n-1 or n-2. For example, if you are on Portworx Backup version 3.0.x or 2.11.x, you can directly upgrade to 3.1.0. If you are on 2.10.x or earlier and want to upgrade to 3.1.0, you need to upgrade in a phased manner. First upgrade to an intermediate version (2.11.x or 3.0.x), and then upgrade to 3.1.0.

note

The same steps in Generate Portworx Backup Spec and Upgrade Portworx Backup Using Helm apply to both internet-connected and air-gapped environments — there isn't a separate guide per environment. Air-gapped-specific instructions (for example, using a custom registry and downloading the Helm chart package locally) are called out inline within those pages wherever the steps diverge.

Upgrade workflow

To upgrade Portworx Backup:

1. Check the Requirements for Upgrading Portworx Backup.
2. On the Portworx Backup cluster, set up the upgrade environment.
3. Generate Portworx Backup Spec for the target version. Use the same Namespace, StorageClass, and installation customizations as your existing deployment. The generated spec serves as input to the Helm upgrade and should preserve your current configuration.
   To avoid disabling previously enabled components, perform the upgrade using your existing Helm values, either through a values file or with --reuse-values, instead of relying only on the newly generated spec. For more information, see Upgrade Portworx Backup Using Helm.
4. Upgrade Portworx Backup using Helm or Argo CD.
5. On the application cluster, upgrade Stork.

After upgrading, see the Configure and Working with Portworx Backup modules for next steps.

Prerequisites

Before starting an upgrade, ensure the following conditions are met:

• Check component compatibility: Verify your Stork and Portworx Enterprise versions are compatible with the target Portworx Backup version. See the Compatibility Matrix.
• kubectl access: Your kubectl context is set to the Portworx Backup cluster with admin privileges.
• Helm version: Helm 3 is installed on the machine running the upgrade command.
• MongoDB pod health: All three MongoDB pods (pxc-backup-mongodb-0, pxc-backup-mongodb-1, pxc-backup-mongodb-2) are in Ready state. The upgrade will fail if any MongoDB pod is not ready. See Pre-upgrade job for recovery steps.
• PVC storage: Sufficient storage is available on the PVCs used by Portworx Backup components.
• pxc-credentials secret: The pxc-credentials secret is present in the Portworx Backup namespace with valid database passwords. See Password Policy.
• Backup your data: Take a backup of critical data before upgrading.
• Version compatibility: Verify the target version is compatible with your current Stork and Portworx Enterprise versions. See the Compatibility Matrix.

Portworx Backup supports upgrades to version n from versions n-1 or n-2. For example, if you are on Portworx Backup version 3.0.x or 2.11.x, you can directly upgrade to 3.1.1. If you are on 2.10.x or earlier and want to upgrade to 3.1.1, you need to upgrade in a phased manner. First upgrade to an intermediate version (2.11.x or 3.0.x), and then upgrade to 3.1.1.

Upgrading to Portworx Backup 2.10.0 or above now requires the pxc-credentials secret for password management. For more information, see the Password Policy guide.

Upgrade matrix

Portworx Backup Version	Intermediate Upgrade Required?	Upgrade Path
3.0.x	No	3.0.x → 3.1.x
2.11.x	No	2.11.x → 3.1.x
2.10.x	Yes	2.10.x → 3.0.x → 3.1.x
2.9.x	Yes	2.9.x → 2.11.x → 3.1.x
2.8.x	Yes	2.8.x → 2.10.x → 3.0.x → 3.1.x
2.7.x	Yes	2.7.x → 2.9.x → 2.11.x → 3.1.x
2.6.x	Yes	2.6.x → 2.8.x → 2.10.x → 3.0.x → 3.1.x
2.5.x	Yes	2.5.x → 2.7.x → 2.9.x → 2.11.x → 3.1.x
2.4.x	Yes	2.4.x → 2.6.x → 2.8.x → 2.10.x → 3.0.x → 3.1.x
2.3.x	Yes	2.3.x → 2.5.x → 2.7.x → 2.9.x → 2.11.x → 3.1.x
2.2.x	Yes	2.2.x → 2.4.x → 2.6.x → 2.8.x → 2.10.x → 3.0.x → 3.1.x
2.1.x	Yes	2.1.x → 2.3.x → 2.5.x → 2.7.x → 2.9.x → 2.11.x → 3.1.x

caution

If you encounter an upgrade failure while upgrading to the latest version of Portworx Backup, avoid rolling back to your previous version using Helm rollback or any other methods. In such situations, do not revert to the previously installed version. Instead, reach out to the Portworx Backup Support team for assistance.

KDMP backup behavior for upgrades

Assume that you are on Portworx Backup version 2.6.0 or below, with cloud native driver installed on your application clusters. When you upgrade to Portworx Backup version 2.7.0 and above from previous versions, the existing manual backups will not be affected:

The backups that are scheduled (to be created in the future) with the cloud native driver:

• Get migrated to CSI snapshots along with the offload-to-backup-location option if a volume snapshot class is available

• Use the KDMP driver to create a direct KDMP backup if a volume snapshot class is not available

  note

  Only scheduled backups created using the cloud native driver before the upgrade are migrated; backups created after the upgrade are not. Scheduled backups created with other drivers remain unchanged. One of the backups might fail after migrating from the native driver to CSI + Offload if the reconciler has not yet updated the schedule CR.