Here’s a thorough explanation of OADP — what it is, how it works, and how to use it.

What OADP is

The OpenShift API for Data Protection (OADP) product safeguards customer applications on OpenShift Container Platform. It offers comprehensive disaster recovery protection, covering OpenShift Container Platform applications, application-related cluster resources, persistent volumes, and internal images. OADP is also capable of backing up both containerized applications and virtual machines. However, OADP does not serve as a disaster recovery solution for etcd or OpenShift Operators.

In plain terms: OADP is the application-layer backup tool for OCP. Where etcd backup protects the cluster skeleton (all resource definitions), OADP protects what’s running inside namespaces — the actual workloads and their data.

OADP is the OpenShift API for Data Protection operator. This open source operator sets up and installs Velero on the OpenShift platform, allowing users to backup and restore applications.

ArchitectureHere’s a comprehensive explanation of OADP across all its key dimensions.

What OADP is

The OpenShift API for Data Protection (OADP) provides a comprehensive solution for backing up and restoring applications, persistent volumes, and custom resources across various environments. OADP is the OpenShift API for Data Protection operator — this open source operator sets up and installs Velero on the OpenShift platform, allowing users to backup and restore applications.

In short: OADP = Velero + OpenShift-specific plugins + OLM lifecycle management. Everything is driven by Kubernetes CRs.

What OADP protects

Data that can be protected with OADP includes Kubernetes resource objects, persistent volumes, and internal images. More specifically:

• Kubernetes objects — all resources in selected namespaces: Deployments, Services, ConfigMaps, Secrets, Routes, PVCs, RoleBindings, etc.
• Internal container images — images stored in the OCP internal registry (built by S2I/Tekton and not pushed externally)
• Persistent volume data — via CSI snapshots, cloud-native snapshots, or file-system backup (Kopia)
• OpenShift Virtualization VMs — OADP can quiesce VMs, snapshot their disks, and restore them fully

What it does NOT protect: OADP does not serve as a disaster recovery solution for etcd or OpenShift Operators. OADP support is applicable to customer workload namespaces and cluster scope resources. Full cluster backup and restore are not supported.

Core components

Step 1 — Install

Install from OperatorHub or via CLI:

cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: redhat-oadp-operator
  namespace: openshift-adp
spec:
  channel: stable-1.5
  name: redhat-oadp-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
EOF

Step 2 — Configure via DataProtectionApplication CR

The DataProtectionApplication (DPA) is the master config CR. It tells OADP where to store backups, which plugins to load, and how to handle PV backup:

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: dpa-cluster
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - openshift   # required — handles Routes, SCCs, internal images
        - aws         # swap for gcp or azure as needed
        - csi         # enables CSI volume snapshots
    nodeAgent:
      enable: true
      uploaderType: kopia   # preferred over restic since OADP 1.3
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        credential:
          name: cloud-credentials
          key: cloud
        objectStorage:
          bucket: my-ocp-backups
          prefix: cluster-prod
        config:
          region: ca-central-1

For on-prem with ODF/NooBaa, use provider: aws with a custom s3Url pointing to the NooBaa S3 Route — no cloud account required.

Step 3 — Take backups

# One-time backup with a pre-hook to quiesce PostgreSQL
apiVersion: velero.io/v1
kind: Backup
metadata:
  name: my-app-backup
  namespace: openshift-adp
spec:
  includedNamespaces: [my-app, my-app-db]
  excludedResources: [events, events.events.k8s.io]
  defaultVolumesToFsBackup: true   # Kopia for PVs
  storageLocation: default
  ttl: 720h0m0s                    # 30-day retention
  hooks:
    resources:
      - name: quiesce-db
        includedNamespaces: [my-app-db]
        labelSelector:
          matchLabels:
            app: postgresql
        pre:
          - exec:
              container: postgresql
              command: ["/bin/bash", "-c", "psql -c 'CHECKPOINT'"]
              timeout: 30s

You can schedule backups at specified intervals. 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.

# Scheduled daily backup
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: openshift-adp
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces: ["*"]
    excludedNamespaces: [openshift-*, kube-*, openshift-adp]
    defaultVolumesToFsBackup: true
    storageLocation: default
    ttl: 168h0m0s   # 7-day retention

Step 4 — Restore

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: my-app-restore
  namespace: openshift-adp
spec:
  backupName: my-app-backup
  restorePVs: true
  existingResourcePolicy: none   # skip resources that already exist

For cross-cluster disaster recovery, point the destination cluster’s DPA at the same S3 bucket with accessMode: ReadOnly, then create the Restore CR. OADP auto-creates the target namespace — don’t pre-create it, as that causes SCC conflicts.

PV backup — three strategies

The underlying mechanism within OADP that allows the backup and restore of persistent volumes is either Restic, Kopia, CSI snapshots, or CSI dataMover. Backups are incremental by default.

OADP 1.3 includes a built-in Data Mover that uses Kopia as the uploader mechanism to read snapshot data and write to a Unified Repository, allowing you to restore stateful applications from a remote object store if a failure or cluster corruption occurs.

Key limits and best practices

• Always exclude events, pods, and replicasets from backups — they are recreated automatically
• Test restores monthly — an untested backup is not a backup
• Pair with etcd backup — OADP covers application data, etcd covers the cluster skeleton; both are needed for full DR
• Use hooks for stateful apps (databases, message queues) to get crash-consistent backups
• Monitor Velero’s Prometheus metrics at /metrics on the Velero pod and alert on backup.status.phase != Completed