Restoring an application

Edit online

OADP restores resources and persistent volumes from a backup archive. Restore can cover either all objects in the backup archive or it can filter the restored objects by namespace, persistent volume, or label.

For restoring an application, a RestoreCustomResource needs to be defined.

Figure 1. Definition of a RestoreCustomResource

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: mysql-restore
  namespace: openshift-adp
spec:
  backupName: mysql-backup
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  restorePVs: true

OADP supports an incremental restore, which makes it possible to only restore data, which has been modified between two backups. To support incremental restore, a new parameter existingResourcePolicy has been added.

Figure 2. Definition of a RestoreCustomResource for an incremental restore

 apiVersion: velero.io/v1
kind: Restore
metadata:
  name: mysql-restore
  namespace: openshift-adp
spec:
  backupName: mysql-backup
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  restorePVs: true
  ExistingResourcePolicy: update

For details see: Add support for Resourcefulness to restore API(GitHub)

For a successful restore of an application to a new Red Hat OpenShift cluster, it is important to maintain the consistency of user ID (UID) of the service account that runs the application. That UID is used to run the application inside the Container.

It is a best practice that the application uses securitycontextconstraints targeting the service account in deployment to allow privileged containers. This means that the service account used in the pod is always the same and has one UID on both backup and restore cluster. Create an SCC or use an existing one that allows custom UID outside of normal allowed namespace UID ranges.

When the application also needs to be run under a specific custom UID, then the Pod definition needs to use a ServiceAccount with the RunAsAny privilege, and the Pod needs to use the runAsUser to set the UID to the hardcoded UID.

Note: Using a hardcoded UID is not recommended. One of the issues with this approach is that it is prone to UID collisions with system UIDs or with UIDs of the same or different application running in a different namespace expecting to use the same UID.

Figure 3. Red Hat OpenShift commands to set UID

oc create sa sa-with-anyuid
oc adm policy add-scc-to-user anyuid -z sa-with-anyuid

Figure 4. Sample Deployment yaml

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      serviceAccountName: sa-with-anyuid
      securityContext:
        runAsUser: 1001
        fsGroup: 1001

For more information on Red Hat OpenShift UIDS, refer to A Guide to OpenShift UIDS

The Red Hat article OpenShift APIs for Data Protection (OADP) FAQ provides details on challenges and workarounds during the restore of an application on new cluster.