---
title: Configuring backup and restore PVCs for Data Mover
---

# Configuring backup and restore PVCs for Data Mover {#configuring-backup-restore-pvc-datamover}

Configure backup and restore persistent volume claims (PVCs) to optimize Data Mover operations. For storage classes like CephFS, these intermediate PVCs allow the system to create read-only volumes from snapshots, resulting in significantly faster backups.

You create a `readonly` backup PVC by using the `nodeAgent.backupPVC` section of the `DataProtectionApplication` (DPA) and setting the `readOnly` access mode to `true`.

You can use the following fields in the `nodeAgent.backupPVC` section of the DPA to configure the backup PVC.

- `storageClass`: The name of the storage class to use for the backup PVC.
- `readOnly`: Indicates if the backup PVC should be mounted as read-only. Setting this field to `true` also requires you to set the `spcNoRelabeling` field to `true`.
- `spcNoRelabeling`: Disables automatic relabeling of the volume if set to `true`. You can set this field to `true` only when `readOnly` is `true`. When the `readOnly` flag is `true`, SELinux relabeling of the volume is not possible. This causes the Data Mover backup to fail. Therefore, when you are using the `readOnly` access mode for the CephFS storage class, you must disable relabeling.

## Configuring a  backup PVC for a Data Mover backup {#configuring-backup-pvc_configuring-backup-restore-pvc-datamover}

Configure backup persistent volume claim (PVC) settings in the `DataProtectionApplication` (DPA) to optimize Data Mover backup performance for different storage classes. The feature gives you read-only access modes for faster data movement.

**Prerequisites**

- You have installed the OADP Operator.

**Procedure**

1. Configure the `nodeAgent.backupPVC` section in the DPA as shown in the following example:

   ```yaml {title="Example Data Protection Application"}
   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
     name: ts-dpa
     namespace: openshift-adp
   spec:
     backupLocations:
     - velero:
         credential:
           key: cloud
           name: cloud-credentials-gcp
         default: true
         objectStorage:
           bucket: oadp...2jw
           prefix: velero
         provider: gcp
     configuration:
       nodeAgent:
         enable: true
         uploaderType: kopia
         backupPVC:
           storage-class-1:
             readOnly: true
             spcNoRelabeling: true
             storageClass: gp3-csi
           storage-class-2:
             readOnly: false
             spcNoRelabeling: false
             storageClass: gp3-csi
       velero:
         defaultPlugins:
         - gcp
         - openshift
         - csi
   ```

   where:

   `backupPVC`
   :   Specifies the `backupPVC` section. In this example, the `backupPVC` section has configurations for two storage classes, `storage-class-1` and `storage-class-2`.

   `readOnly`
   :   Specifies that the `backupPVC` for `storage-class-1` is configured as `readOnly`.

   `spcNoRelabeling`
   :   Specifies that the `spcNoRelabeling` field is set to `true` because the `backupPVC` for `storage-class-1` is `readOnly`.
2. Create a `Backup` custom resource by using the following configuration:

   ```yaml {title="Example Backup"}
   apiVersion: velero.io/v1
   kind: Backup
   metadata:
     name: test-backup
     namespace: openshift-adp
   spec:
     includedNamespaces:
     - <application_namespace>
     snapshotMoveData: true
   ```

   `snapshotMoveData`
   :   Set to `true` for a Data Mover backup.

**Verification**

- Verify that the backup PVCs are created as read-only (`ROX`) by running the following command:

  ```terminal {title="Example command"}
  $ oc get pvc -n openshift-adp -w
  ```

  ```terminal
  test-backup1-l..d   Bound   pvc-1298.....22f8   2Gi        ROX            standard-csi   <unset>                 37s
  test-backup1-l..d   Bound   pvc-1298....022f8   2Gi        ROX            standard-csi   <unset>                 37s
  ```

## Configuring a restorePVC for a Data Mover restore {#configuring-restore-pvc_configuring-backup-restore-pvc-datamover}

Configure restore persistent volume claim (PVC) settings in the `DataProtectionApplication` (DPA) to optimize Data Mover restore operations and enable parallel volume restores. This improves restore performance by distributing restore pods across nodes.

A `restorePVC` is an intermediate PVC that is used to write data during the Data Mover restore operation.

You can configure the `restorePVC` in the `DataProtectionApplication` (DPA) object by using the `ignoreDelayBinding` field. Setting the `ignoreDelayBinding` field to `true` allows the restore operation to ignore the `WaitForFirstConsumer` binding mode. The data movement restore operation then creates the restore pod and provisions the associated volume to an arbitrary node.

The `ignoreDelayBinding` setting is helpful in scenarios where multiple volume restores are happening in parallel. With the `ignoreDelayBinding` field set to `true`, the restore pods can be spread evenly to all nodes.

**Prerequisites**

- You have installed the OADP Operator.
- You have a created a Data Mover backup of an application.

**Procedure**

- Configure the `restorePVC` section in the DPA as shown in the following example:

  ```yaml {title="Example Data Protection Application"}
  apiVersion: oadp.openshift.io/v1alpha1
  kind: DataProtectionApplication
  metadata:
    name: ts-dpa
    namespace: openshift-adp
  spec:
  #  ...
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
      restorePVC:
        ignoreDelayBinding: true
  ```

  where:

  `restorePVC`
  :   Specifies the `restorePVC` section.

  `ignoreDelayBinding`
  :   Set the `ignoreDelayBinding` field to `true`.
