This is a cache of https://docs.okd.io/4.10/backup_and_restore/application_backup_and_restore/installing/about-installing-oadp.html. It is a snapshot of the page at 2024-11-24T22:18:49.091+0000.
About installing OADP - Application backup and restore | Backup and restore | OKD 4.10
  1. Documentation
×

About installing OADP

As a cluster administrator, you install the OpenShift API for Data Protection (OADP) by installing the OADP Operator. The OADP Operator installs Velero 1.7.

Starting from OADP 1.0.4, all OADP 1.0.z versions can only be used as a dependency of the MTC Operator and are not available as a standalone Operator.

To back up Kubernetes resources and internal images, you must have object storage as a backup location, such as one of the following storage types:

The CloudStorage API, which automates the creation of a bucket for object storage, is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

You can back up persistent volumes (PVs) by using snapshots or Restic.

To back up PVs with snapshots, you must have a cloud provider that supports either a native snapshot API or Container Storage Interface (CSI) snapshots, such as one of the following cloud providers:

If your cloud provider does not support snapshots or if your storage is NFS, you can back up applications with Restic backups on object storage.

You create a default Secret and then you install the Data Protection Application.

AWS S3 compatible backup storage providers

OADP is compatible with many object storage providers for use with different backup and snapshot operations. Several object storage providers are fully supported, several are unsupported but known to work, and some have known limitations.

Supported backup storage providers

The following AWS S3 compatible object storage providers, are fully supported by OADP through the AWS plugin for use as backup storage locations:

  • MinIO

  • Multicloud Object Gateway (MCG) with NooBaa

  • Amazon Web Services (AWS) S3

The following compatible object storage providers are supported and have their own Velero object store plugins:

  • Google Cloud Platform (GCP)

  • Microsoft Azure

Unsupported backup storage providers

The following AWS S3 compatible object storage providers, are known to work with Velero through the AWS plugin, for use as backup storage locations, however, they are unsupported and have not been tested by Red Hat:

  • IBM Cloud

  • Oracle Cloud

  • DigitalOcean

  • NooBaa

  • Tencent Cloud

  • Ceph RADOS v12.2.7

  • Quobyte

  • Cloudian HyperStore

Backup storage providers with known limitations

The following AWS S3 compatible object storage providers are known to work with Velero through the AWS plugin with a limited feature set:

  • Swift - It works for use as a backup storage location for backup storage, but is not compatible with Restic for filesystem-based volume backup and restore.

Configuring NooBaa for disaster recovery on OpenShift Data Foundation

If you use cluster storage for your NooBaa bucket backupStorageLocation on OpenShift Data Foundation, configure NooBaa as an external object store.

Failure to configure NooBaa as an external object store might lead to backups not being available.
Procedure
Additional resources

/// Module included in the following assemblies:

About OADP update channels

When you install an OADP Operator, you choose an update channel. This channel determines which upgrades to the OADP Operator and to Velero you receive. You can switch channels at any time.

The following update channels are available:

  • The stable channel is now deprecated. The stable channel contains the patches (z-stream updates) of OADP ClusterServiceVersion for oadp.v1.1.z and older versions from oadp.v1.0.z.

  • The stable-1.0 channel contains oadp.v1.0.z, the most recent OADP 1.0 ClusterServiceVersion.

  • The stable-1.1 channel contains oadp.v1.1.z, the most recent OADP 1.1 ClusterServiceVersion.

  • The stable-1.2 channel contains oadp.v1.2.z, the most recent OADP 1.2 ClusterServiceVersion.

Which update channel is right for you?

  • The stable channel is now deprecated. If you are already using the stable channel, you will continue to get updates from oadp.v1.1.z.

  • Choose the stable-1.y update channel to install OADP 1.y and to continue receiving patches for it. If you choose this channel, you will receive all z-stream patches for version 1.y.z.

When must you switch update channels?

  • If you have OADP 1.y installed, and you want to receive patches only for that y-stream, you must switch from the stable update channel to the stable-1.y update channel. You will then receive all z-stream patches for version 1.y.z.

  • If you have OADP 1.0 installed, want to upgrade to OADP 1.1, and then receive patches only for OADP 1.1, you must switch from the stable-1.0 update channel to the stable-1.1 update channel. You will then receive all z-stream patches for version 1.1.z.

  • If you have OADP 1.y installed, with y greater than 0, and want to switch to OADP 1.0, you must uninstall your OADP Operator and then reinstall it using the stable-1.0 update channel. You will then receive all z-stream patches for version 1.0.z.

You cannot switch from OADP 1.y to OADP 1.0 by switching update channels. You must uninstall the Operator and then reinstall it.

Installation of OADP on multiple namespaces

You can install OADP into multiple namespaces on the same cluster so that multiple project owners can manage their own OADP instance. This use case has been validated with Restic and CSI.

You install each instance of OADP as specified by the per-platform procedures contained in this document with the following additional requirements:

  • All deployments of OADP on the same cluster must be the same version, for example, 1.1.4. Installing different versions of OADP on the same cluster is not supported.

  • Each individual deployment of OADP must have a unique set of credentials and a unique BackupStorageLocation configuration.

  • By default, each OADP deployment has cluster-level access across namespaces. OKD administrators need to review security and RBAC settings carefully and make any necessary changes to them to ensure that each OADP instance has the correct permissions.

Additional resources