OpenShift Backup and Restore with OAPD

Make sure you have the following prerequisites and update the cluster or tooling where needed before moving on.

It provisions an in-cluster, S3-compatible object store that Velero or OADP uses as the backup target where backup metadata and volume backup data are uploaded. The installation is performed using the MinIO Helm chart. You add the MinIO Helm repository, create a minio-values.yaml file to define the deployment mode, and then run helm upgrade --install to deploy MinIO into a dedicated minio namespace.

On OpenShift, you need to grant the MinIO service account the required Security Context Constraints (SCC) to run successfully. Finally, use the MinIO client (mc) inside the pod to create the Velero bucket and a dedicated Velero user with read/write permissions.

helm repo add minio https://charts.min.io/
helm repo update

mode: standalone
persistence:
  enabled: true
  size: 50Gi
resources:
  requests:
    memory: 512Mi
    cpu: 250m
rootUser: "minioadmin"
rootPassword: "minioadmin"
service:
  type: ClusterIP
replicas: 1
console:
  enabled: false

helm upgrade --install minio minio/minio \
  -n minio --create-namespace \
  -f minio-values.yaml \
  --version 5.4.0

oc adm policy add-scc-to-user anyuid -z minio-sa -n minio
oc adm policy who-can use scc anyuid

kubectl exec -it deploy/minio -n minio -- bash
# Inside pod:
mc alias set localminio http://minio:9000 minioadmin minioadmin
mc mb localminio/velero
mc admin user add localminio velero-user vP@assWoRd
mc admin policy attach localminio readwrite --user velero-user
mc ls localminio

Configuring cloud credentials enables Velero to authenticate to the MinIO object storage in order to write backups and read them back during restores. You do this by creating a Kubernetes Secret named cloud-credentials.yaml in the OADP namespace, containing an AWS-style credentials file.

apiVersion: v1
kind: Secret
metadata:
  name: cloud-credentials
  namespace: openshift-adp
stringData:
  cloud: |
    [default]
    aws_access_key_id = velero-user
    aws_secret_access_key = vP@assWoRd

The following table defines each field of the above configuration:

Run the command to apply the secret to the OADP namespace so that OADP/Velero can use these credentials to access the MinIO S3 bucket for backups and restores.

kubectl apply -f cloud-credentials.yaml

The deployment of the DPA custom resource lets OADP configure Velero with the correct settings. This defines Velero’s configuration, plugins, and backup location.

Create a dpa.yaml file in the OADP namespace with your Velero configuration:

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-dpa
  namespace: openshift-adp
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
    velero:
      disableFsBackup: false
      defaultPlugins:
        - openshift
        - aws
        - kubevirt
  backupLocations:
    - velero:
        provider: aws
        objectStorage:
          bucket: velero
          prefix: backups
        config:
          region: minio
          s3ForcePathStyle: "true"
          s3Url: http://minio.minio.svc.cluster.local:9000
        credential:
          name: cloud-credentials
          key: cloud
        default: true

The following table defines each field of the above configuration:

Run the following command to apply, and then verify that the Velero/OADP pods are running:

kubectl apply -f dpa.yaml
kubectl get pods -n openshift-adp

The Velero configuration uses the information to know where backups are stored (bucket/prefix) and how to connect to that storage. The BSL points Velero to the MinIO S3-compatible service and the velero bucket, so backups and restore artifacts are consistently written to the correct location.

Create a tuned BSL for faster uploads, backup-storage-location.yaml.

apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: velero-bsl
  namespace: openshift-adp
spec:
  provider: aws
  objectStorage:
    bucket: velero
    prefix: backups
  config:
    region: minio
    s3ForcePathStyle: 'true'
    s3Url: 'http://minio.minio.svc.cluster.local:9000'
    maxParallel: "10"
    maxRetries: "5"
    maxRetriesBackoff: "2s"
    partSize: "104857600"
  credential:
    name: cloud-credentials
    key: cloud
  default: true

The following table defines each field of the above configuration:

After applying the backup-storage-location.yaml, you can reference it by name, for example, velero-bsl, in backup specs through the storageLocation to ensure backups use the tuned settings. Run the following command:

kubectl apply -f backup-storage-location.yaml

Creating a backup is the step where you define what data and Kubernetes resources Velero should capture and how the backup should be executed and retained.

Create a backup.yaml, adjust names/namespaces:

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: virtana-io-backup-16sep-01
  namespace: openshift-adp
spec:
  csiSnapshotTimeout: 120m0s
  defaultVolumesToFsBackup: true
  includedNamespaces:
    - virtana-io
  itemOperationTimeout: 10h0m0s
  snapshotMoveData: false
  storageLocation: velero-bsl
  ttl: 72h0m0s

The following table defines each field of the above configuration:

Run the following command to apply the backup resource to start the Velero backup job, then list backups in the openshift-adp namespace to confirm it was created and to monitor its status.

kubectl apply -f backup.yaml
velero backup get -n openshift-adp`

In this step, you use Velero through OADP to recreate Kubernetes/OpenShift resources and recover persistent data from a previously completed backup stored in MinIO.

Create a restore.yaml that points to the desired backupName, optionally tunes restore behavior:

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: virtana-io-restore-16sep-01
  namespace: openshift-adp
spec:
  uploaderConfig:
    parallelFilesDownload: 16
  includedNamespaces:
    - virtana-io
  backupName: virtana-io-backup-16sep-01
  restorePVs: true
  restoreVolumes: true
  itemOperationTimeout: 12h

The following table defines each field of the above configuration:

Run the following command to apply restore.yaml and monitor progress and confirm completion using the Velero CLI.

kubectl apply -f restore.yaml
velero restore get -n openshift-adp

In this step, confirm that your Velero/OADP backup and restore actually succeeded at both the Velero control-plane level and at the application level. Validate the resources and application behavior in the restored namespace.

velero backup get -n openshift-adp
velero backup describe virtana-io-backup-16sep-01 -n openshift-adp

velero restore get -n openshift-adp
velero restore describe virtana-io-restore-16sep-01 -n openshift-adp