OADP features and plugins¶

Review OpenShift API for Data Protection (OADP) features and default plugins that integrate Velero with cloud providers to back up and restore OpenShift Container Platform resources. This helps you to select the right plugins and features for your backup and restore environment.

OADP features¶

Review the backup, restore, and scheduling features of OpenShift API for Data Protection (OADP) for protecting applications on OpenShift Container Platform. This helps you to understand the available capabilities for your data protection strategy.

Backup

You can use OADP to back up all applications on the OpenShift Platform, or you can filter the resources by type, namespace, or label.

OADP backs up Kubernetes objects and internal images by saving them as an archive file on object storage. OADP backs up persistent volumes (PVs) by creating snapshots with the native cloud snapshot API or with the Container Storage Interface (CSI). For cloud providers that do not support snapshots, OADP backs up resources and PV data with Restic.

Restore

You can restore resources and PVs from a backup. You can restore all objects in a backup or filter the objects by namespace, PV, or label.

Schedule

You can schedule backups at specified intervals.

Hooks

You can use hooks to run commands in a container on a pod, for example, fsfreeze to freeze a file system. You can configure a hook to run before or after a backup or restore. Restore hooks can run in an init container or in the application container.

OADP plugins¶

Review the default Velero plugins provided by OpenShift API for Data Protection (OADP) that integrate with storage providers to support backup and snapshot operations. This helps you to select and configure the right plugins for your cloud environment.

OADP also provides plugins for OpenShift Container Platform resource backups, OpenShift Virtualization resource backups, and Container Storage Interface (CSI) snapshots.

OADP plugins

1. Mandatory.
2. Virtual machine disks are backed up with CSI snapshots or Restic.
3. The csi plugin uses the Kubernetes CSI snapshot API.
   • OADP 1.1 or later uses snapshot.storage.k8s.io/v1
   • OADP 1.0 uses snapshot.storage.k8s.io/v1beta1
4. Do not add the hypershift plugin in the DataProtectionApplication custom resource if the cluster is not a HyperShift hosted cluster.

About OADP Velero plugins¶

Review how to configure default cloud provider plugins or install custom plugins during the OADP deployment to connect your specific storage solutions. This helps you to successfully back up and restore resources across your environments.

Default Velero cloud provider plugins¶

You can install any of the following default Velero cloud provider plugins when you configure the oadp_v1alpha1_dpa.yaml file during deployment:

• aws (Amazon Web Services)
• gcp (Google Cloud)
• azure (Microsoft Azure)
• openshift (OpenShift Velero plugin)
• csi (Container Storage Interface)
• kubevirt (KubeVirt)

You specify the desired default plugins in the oadp_v1alpha1_dpa.yaml file during deployment.

The following .yaml file installs the openshift, aws, azure, and gcp plugins:

 apiVersion: oadp.openshift.io/v1alpha1
 kind: DataProtectionApplication
 metadata:
   name: dpa-sample
 spec:
   configuration:
     velero:
       defaultPlugins:
       - openshift
       - aws
       - azure
       - gcp

Custom Velero plugins¶

You can install a custom Velero plugin by specifying the plugin image and name when you configure the oadp_v1alpha1_dpa.yaml file during deployment.

You specify the desired custom plugins in the oadp_v1alpha1_dpa.yaml file during deployment.

The following .yaml file installs the default openshift, azure, and gcp plugins and a custom plugin that has the name custom-plugin-example and the image quay.io/example-repo/custom-velero-plugin:

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: dpa-sample
spec:
 configuration:
   velero:
     defaultPlugins:
     - openshift
     - azure
     - gcp
     customPlugins:
     - name: custom-plugin-example
       image: quay.io/example-repo/custom-velero-plugin

Supported architectures for OADP¶

Review the architectures supported by OpenShift API for Data Protection (OADP). This helps you to verify compatibility with your cluster infrastructure.

• AMD64
• ARM64
• PPC64le
• s390x

OADP support for IBM Power and IBM Z¶

Review OpenShift API for Data Protection (OADP) support and tested backup locations for IBM Power(R) and IBM Z(R). This helps you to verify compatibility and supported configurations for your IBM Power(R) or IBM Z(R) environment.

• OADP 1.3.6 was tested successfully against OpenShift Container Platform 4.12, 4.13, 4.14, and 4.15 for both IBM Power(R) and IBM Z(R). The sections that follow give testing and support information for OADP 1.3.6 in terms of backup locations for these systems.
• OADP 1.4.6 was tested successfully against OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17 for both IBM Power(R) and IBM Z(R). The sections that follow give testing and support information for OADP 1.4.6 in terms of backup locations for these systems.
• OADP 1.5.5 was tested successfully against OpenShift Container Platform 4.19 for both IBM Power(R) and IBM Z(R). The sections that follow give testing and support information for OADP 1.5.5 in terms of backup locations for these systems.

OADP support for target backup locations using IBM Power¶

Review the tested and supported configurations for running OADP on IBM Power(R) with various OpenShift Container Platform versions and S3-compatible backup locations. This helps you to verify that your IBM Power(R) environment is supported before configuring backups.

• IBM Power(R) running with OpenShift Container Platform 4.12, 4.13, 4.14, and 4.15, and OADP 1.3.6 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Power(R) with OpenShift Container Platform 4.13, 4.14, and 4.15, and OADP 1.3.6 against all S3 backup location targets, which are not AWS, as well.
• IBM Power(R) running with OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and OADP 1.4.6 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Power(R) with OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and OADP 1.4.6 against all S3 backup location targets, which are not AWS, as well.
• IBM Power(R) running with OpenShift Container Platform 4.19 and OADP 1.5.5 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Power(R) with OpenShift Container Platform 4.19 and OADP 1.5.5 against all S3 backup location targets, which are not AWS, as well.

OADP testing and support for target backup locations using IBM Z¶

Review the tested and supported OADP and OpenShift Container Platform version combinations for IBM Z(R) against S3 backup location targets. This helps you verify that your IBM Z(R) environment and OADP version are supported for backup operations.

• IBM Z(R) running with OpenShift Container Platform 4.12, 4.13, 4.14, and 4.15, and 1.3.6 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Z(R) with OpenShift Container Platform 4.13 4.14, and 4.15, and 1.3.6 against all S3 backup location targets, which are not AWS, as well.
• IBM Z(R) running with OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and 1.4.6 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Z(R) with OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and 1.4.6 against all S3 backup location targets, which are not AWS, as well.
• IBM Z(R) running with OpenShift Container Platform 4.19 and OADP 1.5.5 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Z(R) with OpenShift Container Platform 4.19 and OADP 1.5.5 against all S3 backup location targets, which are not AWS, as well.

Known issue of OADP using IBM Power(R) and IBM Z(R) platforms¶

Use only NFS storage with File System Backup (FSB) methods such as Kopia or Restic for Single-node OpenShift clusters on IBM Power(R) and IBM Z(R) platforms. This helps you to avoid unsupported backup configurations on these platforms.

There is currently no workaround for this restriction.

OADP and FIPS¶

Federal Information Processing Standards (FIPS) are a set of computer security standards developed by the United States federal government inline with the Federal Information Security Management Act (FISMA).

OpenShift API for Data Protection (OADP) has been tested and works on FIPS-enabled OpenShift Container Platform clusters.

Avoiding the Velero plugin panic error¶

Label a custom Backup Storage Location (BSL) to resolve Velero plugin panic errors during imagestream backups. This helps you to ensure the OADP controller creates the required registry secret when you manage the BSL outside the DataProtectionApplication (DPA) CR.

A missing secret can cause a panic error for the Velero plugin during image stream backups. When the backup and the BSL are managed outside the scope of the DPA, the OADP controller does not create the relevant oadp-<bsl_name>-<bsl_provider>-registry-secret parameter.

During the backup operation, the OpenShift Velero plugin panics on the imagestream backup, with the following panic error:

024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item"
backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io,
namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked:
runtime error: index out of range with length 1, stack trace: goroutine 94…

Procedure

1. Label the custom BSL with the relevant label by using the following command:
   terminal

   $ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl

2. After the BSL is labeled, wait until the DPA reconciles.
   Note

   You can force the reconciliation by making any minor change to the DPA itself.

Verification

• After the DPA is reconciled, confirm that the parameter has been created and that the correct registry data has been populated into it by entering the following command:
  terminal

  $ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'

Workaround for OpenShift ADP Controller segmentation fault¶

Define either velero or cloudstorage in your Data Protection Application (DPA) configuration to prevent indefinite pod crashes. This configuration resolves a segmentation fault in the openshift-adp-controller-manager pod that occurs when both components are enabled.

The openshift-adp-controller-manager pod fails with a crash loop segmentation fault due to the following settings:

• If you define both velero and cloudstorage, the openshift-adp-controller-manager fails.
• If you do not define both velero and cloudstorage, the openshift-adp-controller-manager fails.

See OADP-1054 for more information.