Understanding OADP: Red Hat’s OpenShift Data Protection Solution

techhadoop OCP

OADP stands for OpenShift API for Data Protection. In OpenShift, it is Red Hat’s supported way to back up and restore applications and their data. OADP uses Velero underneath, but packages it into an OpenShift Operator with supported plugins and OpenShift-specific integration. (Red Hat Documentation)

A simple way to remember it is:

OADP = Operator + Velero + Storage plugins + OpenShift integration

What OADP protects

OADP can protect application-related Kubernetes/OpenShift resources such as:

Deployment
Service
ConfigMap
Secret
Route
PVC
PV data
Custom Resources
Internal images

It can back up an entire application namespace or select resources using namespaces, resource types, or labels. Persistent-volume data can be protected using storage snapshots, CSI snapshots, or filesystem backup depending on your storage and OADP configuration. (Red Hat Documentation)

For example:

Namespace: banking-app
Deployment
   |
Service
   |
Route
   |
ConfigMap / Secret
   |
PVC
   |
Application Data

OADP can capture these application components so that the application can later be restored.

OADP architecture

A typical deployment looks like:

                     OpenShift Cluster
                ┌─────────────────────────┐
                │                         │
                │      OADP Operator      │
                │             │           │
                │             ▼           │
                │          Velero         │
                │        Controller       │
                │             │           │
                │      ┌──────┴──────┐    │
                │      │             │    │
                │      ▼             ▼    │
                │ Kubernetes      PV Data │
                │ Resources          │    │
                │      │             │    │
                └──────┼─────────────┼────┘
                       │             │
                       ▼             ▼
                  Object Storage   Snapshot/
                    S3 / Blob        CSI

The Kubernetes resource metadata is normally stored in object storage. Depending on the architecture, persistent data might be stored through CSI/native snapshots or copied into backup storage.

Supported object-storage options include AWS S3, Azure storage, Google Cloud storage, OpenShift Data Foundation/MCG, and S3-compatible storage. (Red Hat Documentation)

The important OADP components

The first component to understand is the OADP Operator.

You install it through OperatorHub. It normally operates in:

openshift-adp

Check it with:

oc get pods -n openshift-adp

The Operator manages the OADP/Velero configuration.

The second major component is the DataProtectionApplication, or DPA. This is the primary OADP configuration object.

oc get dpa -n openshift-adp

You configure things like:

Cloud provider
Storage location
Credentials
Velero plugins
CSI support
Node agent
Data mover

Conceptually:

DPA
 |
 +-- AWS/Azure/GCP plugin
 |
 +-- Backup storage location
 |
 +-- CSI
 |
 +-- Node Agent
 |
 +-- Velero

Backup Storage Location — BSL

The BackupStorageLocation tells Velero where backup metadata and data should be stored.

Check it with:

oc get bsl -n openshift-adp

Example:

NAME      PHASE
default   Available

For AWS this could point to:

S3 bucket
   |
   └── openshift-backups/
         ├── backup01
         ├── backup02
         └── backup03

For Azure it might be an Azure Blob Storage container.

Volume Snapshot Location

If you use cloud-native volume snapshots, OADP can configure a VolumeSnapshotLocation:

oc get vsl -n openshift-adp

For example:

Application PVC
      |
      ▼
Cloud Disk
      |
      ▼
EBS Snapshot

On AWS:

PVC → EBS → EBS Snapshot

On Azure:

PVC → Managed Disk → Snapshot

With CSI:

PVC
 |
 ▼
CSI Driver
 |
 ▼
VolumeSnapshot

Red Hat documents native cloud snapshots and CSI snapshots as supported ways to protect persistent volumes where the storage provider supports them. (Red Hat Documentation)

How a backup works

Suppose you have:

Namespace: payment-app

containing:

Deployment
Service
Route
Secret
ConfigMap
PVC

You create an OADP/Velero Backup resource:

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: payment-backup
  namespace: openshift-adp
spec:
  includedNamespaces:
    - payment-app

Apply it:

oc apply -f backup.yaml

Then:

Backup CR
    |
    ▼
Velero
    |
    +------ Kubernetes API
    |           |
    |           ▼
    |       Resources
    |
    +------ Persistent Volume
                |
                ▼
          Snapshot / FSB

Check progress:

oc get backup -n openshift-adp

Expected:

NAME               STATUS
payment-backup     Completed

How restore works

Suppose somebody accidentally deletes:

payment-app

You can create:

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: payment-restore
  namespace: openshift-adp
spec:
  backupName: payment-backup

Apply:

oc apply -f restore.yaml

The flow becomes:

Object Storage
      |
      ▼
    Velero
      |
      ▼
 Kubernetes API
      |
      ▼
Namespace
Deployment
Service
Route
Secret
PVC
      |
      ▼
Persistent Data

Check:

oc get restore -n openshift-adp

You can also restore an application into a different namespace, which is useful for DR testing. Red Hat explicitly documents namespace-mapped restores as a supported use case. (Red Hat Documentation)

Scheduled backups

You normally don’t create production backups manually every day.

OADP supports Velero schedules:

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: openshift-adp
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
      - payment-app

This runs every day at:

02:00

Check:

oc get schedule -n openshift-adp

A production strategy might look like:

Daily backup
     |
     ├── Monday
     ├── Tuesday
     ├── Wednesday
     ├── Thursday
     ├── Friday
     ├── Saturday
     └── Sunday
Retention: 30 days

Backup hooks

OADP also supports hooks.

This is important for applications such as databases.

Imagine:

PostgreSQL
   |
write transactions
   |
OADP starts backup

Taking a raw filesystem backup while the database is actively writing can result in an application-inconsistent backup.

You can use a hook to perform something like:

Pre-backup
   |
   ▼
Quiesce application
   |
   ▼
Take backup
   |
   ▼
Post-backup
   |
   ▼
Resume application

Red Hat documents backup and restore hooks as part of OADP functionality. (Red Hat Documentation)

OADP vs Velero

A common interview question is:

What’s the difference between OADP and Velero?

Think:

Velero
   =
Upstream Kubernetes backup project
OADP
   =
Red Hat supported data-protection solution
built around Velero
+
OpenShift Operator
+
Cloud/storage plugins
+
OpenShift integration

So in OpenShift production environments, you generally talk about OADP, even though Velero is doing much of the underlying backup/restore work.

Very important: OADP is NOT etcd backup

This distinction is crucial.

             OpenShift DR
                  |
        ┌─────────┴─────────┐
        │                   │
        ▼                   ▼
      OADP              etcd backup
        │                   │
Application backup      Control-plane
and application data      recovery

OADP

Used for:

Applications
Namespaces
PVCs
Application objects
VM workloads (supported configurations)

etcd backup

Used for:

OpenShift control-plane recovery
Cluster state
API objects
Catastrophic cluster recovery

Red Hat specifically states that OADP is not a disaster-recovery solution for etcd or OpenShift Operators, and full-cluster backup/restore through OADP is not supported. (Red Hat Documentation)

So for serious DR you generally want both:

OpenShift DR Strategy
1. etcd snapshots
        +
2. OADP application backups
        +
3. Persistent data protection
        +
4. Infrastructure-as-Code
        +
5. Off-cluster/object storage

OADP and OpenShift Virtualization

OADP can also protect supported OpenShift Virtualization workloads.

Conceptually:

OpenShift VM
    |
    +--- VM definition
    |
    +--- DataVolume
    |
    +--- PVC
          |
          ▼
     CSI Snapshot
          |
          ▼
     Object Storage

Current Red Hat documentation supports OADP backup/restore for OpenShift Virtualization using supported CSI-based approaches and compatible OADP versions. (Red Hat Documentation)

Commands I would memorize for an interview

oc get pods -n openshift-adp
oc get dpa -n openshift-adp
oc get bsl -n openshift-adp
oc get vsl -n openshift-adp
oc get backup -n openshift-adp
oc get restore -n openshift-adp
oc get schedule -n openshift-adp
oc describe backup <backup> -n openshift-adp
oc describe restore <restore> -n openshift-adp

And for troubleshooting:

oc logs deployment/velero \
  -n openshift-adp

Interview answer

A strong 60-second answer would be:

OADP, or OpenShift API for Data Protection, is Red Hat’s supported application backup and restore solution for OpenShift. It is based on Velero and is deployed using the OADP Operator. OADP protects Kubernetes and OpenShift application resources as well as persistent-volume data. Kubernetes metadata is normally stored in object storage such as AWS S3 or Azure Blob, while persistent volumes can be protected through CSI or native storage snapshots, or filesystem-based backup depending on the storage configuration. The main configuration resource is the DataProtectionApplication, and backups and restores are managed using Velero Backup, Restore and Schedule custom resources. An important distinction is that OADP protects application workloads; it does not replace etcd backup for OpenShift control-plane disaster recovery.

For an OCP Architect interview, the key sentence to remember is:

“etcd protects the cluster state; OADP protects the applications.” (Red Hat Documentation)

Leave a Reply