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:
S3-compatible object storage, such as Noobaa or Minio
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:
CSI snapshot-enabled cloud provider, such as OpenShift Data Foundation
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.
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.
Configure NooBaa as an external object store as described in Adding storage resources for hybrid or Multicloud.
Overview of backup locations and snapshot locations in the Velero documentation.
/// Module included in the following assemblies:
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
oadp.v1.1.z and older versions from
The stable-1.0 channel contains
oadp.v1.0.z, the most recent OADP 1.0
The stable-1.1 channel contains
oadp.v1.1.z, the most recent OADP 1.1
The stable-1.2 channel contains
oadp.v1.2.z, the most recent OADP 1.2
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
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.
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
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.