Processing a backup with OADP

Edit online

OADP backups up all resources in a cluster, which belong to a defined namespace. OADP supports both scheduled and on-demand backups. The scheduling capabilities allow specifying intervals of the backup snapshot.

The configuration steps for setting up a backup include defining the target location and the access credentials for the backup archive, typically a S3 bucket in a cloud-based object store.

When the location is defined, a DataProtectionApplication is created. If CSI snapshots are used for backing up the PersistentVolume (PV), then the VolumeSnapshotClass custom resource needs to be defined as well. Volumesnapshotclass specifies the storage provider-specific parameters to use when creating a snapshot of the persistent volume.

Figure 1. Sample definition of a DataProtectionApplication using CSI snapshots
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  namespace: openshift-adp
  name: example-velero
spec:
  backupLocations:
    - velero:
        config:
          profile: 'default'
          region: us-east-1
        credential:
          key: cloud
          name: cloud-credentials
        default: true
        objectStorage:
          bucket: kvmtestbucket
          prefix: 'velero'
        provider: aws
configuration:
    restic:
      enable: false
    velero:
      defaultPlugins:
        - openshift
        - aws
        - csi
    featureFlags:
        - EnableCSI

To back up an application namespace, a BackupCustomResource must be defined.

Figure 2. Sample definition of a BackupCustomResource using CSI snapshots
apiVersion: velero.io/v1
kind: Backup
metadata:
  name: mysql-backup
  labels:
    velero.io/storage-location: default
  namespace: openshift-adp
spec:
  hooks: {}
  includedNamespaces:
  - mysql-persistent
  storageLocation: example-velero-1
  defaultVolumesToRestic: true
  snapshotVolumes: false
  ttl: 0h10m0s

Based on the parameters specified in the BackupCustomResource, the actual backup process will be triggered by OADP. In case of a scheduled backup, a Schedule CR must be defined in addition.

Data Mover for CSI Snapshots

Another key feature is the Volume Snapshot Mover or the Data Mover feature. The OADP Operator supports backup and restore of applications that are backed by CSI volumes by taking advantage of the Velero CSI plug-in. The problem with CSI snapshots on some storage solutions, such as IBM Fusion Data Foundation, is that these snapshots are local to the RHOCP cluster and cannot be recovered if the cluster gets deleted accidentally or if there is a disaster. To overcome this issue, Data Mover is made available for users to save the snapshots in a remote storage.

VolSync is used as the default data mover for OADP. To use this feature, the VolSync Operator must be installed from the operator hub.

Multiple Label Selector

There is also support for the Multiple Label Selector. This enables the support for backing up resources based on multiple labels (or Logic) in a single backup config.

Multiple label selectors can be provided in the specification of the backup custom resource.

Figure 3. Sample definition of a LabelSelectors using CSI snapshots
spec:
  orLabelSelectors:
  - matchLabels:
      app: mysql
  - matchLabels:
      testing: foo

More information on how to install and use the OADP Operator is included in the Red Hat OpenShift Container Platform documentation:

OADP backing up

Back up and restore

Volume Snapshots

Note:
  • CSI backups might fail due to a Ceph limitation of VolumeSnapshotContent snapshots per PVC, and manual intervention might be needed to remove VolumeSnapshotContent as the default policy of VolumeSnapsHotclass is to retain and not delete.
  • You can create many snapshots of the same persistent volume claim (PVC) but cannot schedule periodic creation of snapshots: For CephFS, you can create up to 100 snapshots per PVC. For RADOS Block Device (RBD), you can create up to 512 snapshots for each PVC. (OADP-804) and (OADP-975)

To further enhance the usage of OADP, it is also possible to use hooks to run commands in a container on a pod. This can give the application the chance to assume a well-defined state before the backup initiation, for example, fsfreeze to freeze a file system. Those hooks can be configured to run before or after a backup or restore. Restore hooks can run during initialization of the application container.