Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 4. Application backup and restore

4.1. OADP features and plugins
Copiar enlace

OpenShift API for Data Protection (OADP) features provide options for backing up and restoring applications.

The default plugins enable Velero to integrate with certain cloud providers and to back up and restore OpenShift Container Platform resources.

4.1.1. OADP features
Copiar enlace

OpenShift API for Data Protection (OADP) supports the following features:

Backup

You can back up all resources in your cluster or you can filter the resources by type, namespace, or label.

OADP backs up Kubernetes objects and internal images by saving them as an archive file on object storage. OADP backs up persistent volumes (PVs) by creating snapshots with the native cloud snapshot API or with the Container Storage Interface (CSI). For cloud providers that do not support snapshots, OADP backs up resources and PV data with Restic.

Restore
You can restore resources and PVs from a backup. You can restore all objects in a backup or filter the restored objects by namespace, PV, or label.
Schedule
You can schedule backups at specified intervals.
Hooks
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. Restore hooks can run in an init container or in the application container.

4.1.2. OADP plugins
Copiar enlace

The OpenShift API for Data Protection (OADP) provides default Velero plugins that are integrated with storage providers to support backup and snapshot operations. You can create custom plugins based on the Velero plugins.

OADP also provides plugins for OpenShift Container Platform resource backups and Container Storage Interface (CSI) snapshots.

Expand
Table 4.1. OADP plugins
OADP pluginFunctionStorage location

aws

Backs up and restores Kubernetes objects by using object store.

AWS S3

Backs up and restores volumes by using snapshots.

AWS EBS 

azure

Backs up and restores Kubernetes objects by using object store.

Microsoft Azure Blob storage

Backs up and restores volumes by using snapshots.

Microsoft Azure Managed Disks 

gcp

Backs up and restores Kubernetes objects by using object store.

Google Cloud Storage

Backs up and restores volumes by using snapshots.

Google Compute Engine Disks 

openshift

Backs up and restores OpenShift Container Platform resources by using object store. [1]

Object store 

csi

Backs up and restores volumes by using CSI snapshots. [2]

Cloud storage that supports CSI snapshots

  1. Mandatory.
  2. The 
    csi
    plugin uses the Velero CSI beta snapshot API.

4.1.3. About OADP Velero plugins
Copiar enlace

You can configure two types of plugins when you install Velero:

  • Default cloud provider plugins
  • Custom plugins

Both types of plugin are optional, but most users configure at least one cloud provider plugin.

4.1.3.1. Default Velero cloud provider plugins
Copiar enlace

You can install any of the following default Velero cloud provider plugins when you configure the 

oadp_v1alpha1_dpa.yaml
file during deployment: 

  • aws
    (Amazon Web Services) 
  • gcp
    (Google Cloud Platform) 
  • azure
    (Microsoft Azure) 
  • openshift
    (OpenShift Velero plugin) 
  • csi
    (Container Storage Interface) 
  • kubevirt
    (KubeVirt)

You specify the desired default plugins in the 

oadp_v1alpha1_dpa.yaml
file during deployment.

Example file

The following 

.yaml
file installs the 
openshift
, 
aws
, 
azure
, and 
gcp
plugins: 

 apiVersion: oadp.openshift.io/v1alpha1
 kind: DataProtectionApplication
 metadata:
   name: dpa-sample
 spec:
   configuration:
     velero:
       defaultPlugins:
       - openshift
       - aws
       - azure
       - gcp

4.1.3.2. Custom Velero plugins
Copiar enlace

You can install a custom Velero plugin by specifying the plugin 

image
and 
name
when you configure the 
oadp_v1alpha1_dpa.yaml
file during deployment.

You specify the desired custom plugins in the 

oadp_v1alpha1_dpa.yaml
file during deployment.

Example file

The following 

.yaml
file installs the default 
openshift
, 
azure
, and 
gcp
plugins and a custom plugin that has the name 
custom-plugin-example
and the image 
quay.io/example-repo/custom-velero-plugin
: 

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: dpa-sample
spec:
 configuration:
   velero:
     defaultPlugins:
     - openshift
     - azure
     - gcp
     customPlugins:
     - name: custom-plugin-example
       image: quay.io/example-repo/custom-velero-plugin

4.2. Installing and configuring OADP
Copiar enlace

4.2.1. About installing OADP
Copiar enlace

As a cluster administrator, you install the OpenShift API for Data Protection (OADP) by installing the OADP Operator. The OADP Operator installs Velero 1.7.

To back up Kubernetes resources and internal images, you must have object storage as a backup location, such as one of the following storage types:

Important

The 

CloudStorage
API for S3 storage is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

You can back up persistent volumes (PVs) by using snapshots or Restic.

To back up PVs with snapshots, you must have a cloud provider that supports either a native snapshot API or Container Storage Interface (CSI) snapshots, such as one of the following cloud providers:

If your cloud provider does not support snapshots or if your storage is NFS, you can back up applications with Restic.

You create a 

Secret
object for your storage provider credentials and then you install the Data Protection Application.

Additional resources

You install the OpenShift API for Data Protection (OADP) with Amazon Web Services (AWS) by installing the OADP Operator, configuring AWS for Velero, and then installing the Data Protection Application.

Important

The 

CloudStorage
API for S3 storage is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

To install the OADP Operator in a restricted network environment, you must first disable the default OperatorHub sources and mirror the Operator catalog. See Using Operator Lifecycle Manager on restricted networks for details.

4.2.2.1. Installing the OADP Operator
Copiar enlace

You install the OpenShift API for Data Protection (OADP) Operator on OpenShift Container Platform 4.8 by using Operator Lifecycle Manager (OLM).

The OADP Operator installs Velero 1.7.

Prerequisites

  • You must be logged in as a user with 
    cluster-admin
    privileges.

Procedure

  1. In the OpenShift Container Platform web console, click Operators OperatorHub.
  2. Use the Filter by keyword field to find the OADP Operator.
  3. Select the OADP Operator and click Install.
  4. Click Install to install the Operator in the 
    openshift-adp
    project.
  5. Click Operators Installed Operators to verify the installation.

4.2.2.2. Configuring Amazon Web Services S3
Copiar enlace

You can configure an Amazon Web Services (AWS) S3 storage bucket as a replication repository for the Migration Toolkit for Containers (MTC).

Prerequisites

  • The AWS S3 storage bucket must be accessible to the source and target clusters.
  • You must have the AWS CLI installed.

  • If you are using the snapshot copy method:

    • You must have access to EC2 Elastic Block Storage (EBS).
    • The source and target clusters must be in the same region.
    • The source and target clusters must have the same storage class.
    • The storage class must be compatible with snapshots.

Procedure

  1. Create an AWS S3 bucket: 

    $ aws s3api create-bucket \
    --bucket <bucket> \
    1 
    
    --region <bucket_region>
    2
    1
    Specify your S3 bucket name.
    2
    Specify your S3 bucket region, for example, us-east-1.

  2. Create the IAM user 

    velero
    : 

    $ aws iam create-user --user-name velero

  3. Create an EC2 EBS snapshot policy: 

    $ cat > velero-ec2-snapshot-policy.json <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeVolumes",
                "ec2:DescribeSnapshots",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:CreateSnapshot",
                "ec2:DeleteSnapshot"
            ],
            "Resource": "*"
        }
    ]
}
EOF

  4. Create an AWS S3 access policy for one or for all S3 buckets: 

    $ cat > velero-s3-policy.json <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:PutObject",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::<bucket>/*"
    1 
    
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": [
                "arn:aws:s3:::<bucket>"
    2 
    
            ]
        }
    ]
}
EOF
    1 2
    To grant access to a single S3 bucket, specify the bucket name. To grant access to all AWS S3 buckets, specify * instead of a bucket name as in the following example:

    Example output

    "Resource": [
    "arn:aws:s3:::*"

  5. Attach the EC2 EBS policy to 

    velero
    : 

    $ aws iam put-user-policy \
  --user-name velero \
  --policy-name velero-ebs \
  --policy-document file://velero-ec2-snapshot-policy.json

  6. Attach the AWS S3 policy to 

    velero
    : 

    $ aws iam put-user-policy \
  --user-name velero \
  --policy-name velero-s3 \
  --policy-document file://velero-s3-policy.json

  7. Create an access key for 

    velero
    : 

    $ aws iam create-access-key --user-name velero
{
  "AccessKey": {
        "UserName": "velero",
        "Status": "Active",
        "CreateDate": "2017-07-31T22:24:41.576Z",
        "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
    1 
    
        "AccessKeyId": <AWS_ACCESS_KEY_ID>
    2 
    
    }
}

  8. Create a 

    credentials-velero
    file: 

    $ cat << EOF > ./credentials-velero
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
EOF

    You use the 

    credentials-velero
    file to create a 
    Secret
    object for AWS before you install the Data Protection Application.

4.2.2.3. Creating a secret for backup and snapshot locations
Copiar enlace

You create a 

Secret
object for the backup and snapshot locations if they use the same credentials.

The default name of the 

Secret
is 
cloud-credentials
.

Prerequisites

  • Your object storage and cloud storage must use the same credentials.
  • You must configure object storage for Velero.

  • You must create a 

    credentials-velero
    file for the object storage in the appropriate format.

    Note

    The 

    DataProtectionApplication
    custom resource (CR) requires a 
    Secret
    for installation. If no 
    spec.backupLocations.credential.name
    value is specified, the default name is used.

    If you do not want to specify the backup locations or the snapshot locations, you must create a 

    Secret
    with the default name by using an empty 
    credentials-velero
    file.

Procedure

  • Create a 

    Secret
    with the default name: 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

The 

Secret
is referenced in the 
spec.backupLocations.credential
block of the 
DataProtectionApplication
CR when you install the Data Protection Application.

If your backup and snapshot locations use different credentials, you create separate profiles in the 

credentials-velero
file.

Then, you create a 

Secret
object and specify the profiles in the 
DataProtectionApplication
custom resource (CR).

Procedure

  1. Create a 

    credentials-velero
    file with separate profiles for the backup and snapshot locations, as in the following example: 

    [backupStorage]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>

[volumeSnapshot]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>

  2. Create a 

    Secret
    object with the 
    credentials-velero
    file: 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    1

  3. Add the profiles to the 

    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
        config:
          region: us-east-1
          profile: "backupStorage"
        credential:
          key: cloud
          name: cloud-credentials
  snapshotLocations:
    - name: default
      velero:
        provider: aws
        config:
          region: us-west-2
          profile: "volumeSnapshot"

4.2.2.4. Configuring the Data Protection Application
Copiar enlace

You can configure Velero resource allocations and enable self-signed CA certificates.

4.2.2.4.1. Setting Velero CPU and memory resource allocations
Copiar enlace

You set the CPU and memory resource allocations for the 

Velero
pod by editing the 
DataProtectionApplication
custom resource (CR) manifest.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the values in the 

    spec.configuration.velero.podConfig.ResourceAllocations
    block of the 
    DataProtectionApplication
    CR manifest, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    1 2 1 1
    Specify the value in millicpus or CPU units. Default value is 500m or 1 CPU unit.
    2
    Default value is 512Mi.
    3
    Default value is 500m or 1 CPU unit.
    4
    Default value is 256Mi.
4.2.2.4.2. Enabling self-signed CA certificates
Copiar enlace

You must enable a self-signed CA certificate for object storage by editing the 

DataProtectionApplication
custom resource (CR) manifest to prevent a 
certificate signed by unknown authority
error.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the 

    spec.backupLocations.velero.objectStorage.caCert
    parameter and 
    spec.backupLocations.velero.config
    parameters of the 
    DataProtectionApplication
    CR manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    1
    Specify the Base46-encoded CA certificate string.
    2
    Must be false to disable SSL/TLS security.

4.2.2.5. Installing the Data Protection Application
Copiar enlace

You install the Data Protection Application (DPA) by creating an instance of the 

DataProtectionApplication
API.

Prerequisites

  • You must install the OADP Operator.
  • You must configure object storage as a backup location.
  • If you use snapshots to back up PVs, your cloud provider must support either a native snapshot API or Container Storage Interface (CSI) snapshots.
  • If the backup and snapshot locations use the same credentials, you must create a 
    Secret
    with the default name, 
    cloud-credentials
    .

  • If the backup and snapshot locations use different credentials, you must create a 

    Secret
    with the default name, 
    cloud-credentials
    , which contains separate profiles for the backup and snapshot location credentials.

    Note

    If you do not want to specify backup or snapshot locations during the installation, you can create a default 

    Secret
    with an empty 
    credentials-velero
    file. If there is no default 
    Secret
    , the installation will fail.

Procedure

  1. Click Operators Installed Operators and select the OADP Operator.
  2. Under Provided APIs, click Create instance in the DataProtectionApplication box.

  3. Click YAML View and update the parameters of the 

    DataProtectionApplication
    manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - openshift
    1 
    
        - aws
    restic:
      enable: true
    2 
    
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket_name>
    3 
    
          prefix: <prefix>
    4 
    
        config:
          region: <region>
          profile: "default"
        credential:
          key: cloud
          name: cloud-credentials
    5 
    
  snapshotLocations:
    6 
    
    - name: default
      velero:
        provider: aws
        config:
          region: <region>
    7 
    
          profile: "default"
    1
    The openshift plugin is mandatory in order to back up and restore namespaces on an OpenShift Container Platform cluster.
    2
    Set to false if you want to disable the Restic installation. Restic deploys a daemon set, which means that each worker node has Restic pods running. You configure Restic for backups by adding spec.defaultVolumesToRestic: true to the Backup CR.
    3
    Specify a bucket as the backup storage location. If the bucket is not a dedicated bucket for Velero backups, you must specify a prefix.
    4
    Specify a prefix for Velero backups, for example, velero, if the bucket is used for multiple purposes.
    5
    Specify the name of the Secret object that you created. If you do not specify this value, the default name, cloud-credentials, is used. If you specify a custom name, the custom name is used for the backup location.
    6
    You do not need to specify a snapshot location if you use CSI snapshots or Restic to back up PVs.
    7
    The snapshot location must be in the same region as the PVs.
  4. Click Create.

  5. Verify the installation by viewing the OADP resources: 

    $ oc get all -n openshift-adp

    Example output

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s

4.2.2.5.1. Enabling CSI in the DataProtectionApplication CR
Copiar enlace

You enable the Container Storage Interface (CSI) in the 

DataProtectionApplication
custom resource (CR) in order to back up persistent volumes with CSI snapshots.

Prerequisites

  • The cloud provider must support CSI snapshots.

Procedure

  • Edit the 

    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    1
    Add the csi default plugin.
    2
    Add the EnableCSI feature flag.

You install the OpenShift API for Data Protection (OADP) with Microsoft Azure by installing the OADP Operator, configuring Azure for Velero, and then installing the Data Protection Application.

Important

The 

CloudStorage
API for S3 storage is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

To install the OADP Operator in a restricted network environment, you must first disable the default OperatorHub sources and mirror the Operator catalog. See Using Operator Lifecycle Manager on restricted networks for details.

4.2.3.1. Installing the OADP Operator
Copiar enlace

You install the OpenShift API for Data Protection (OADP) Operator on OpenShift Container Platform 4.8 by using Operator Lifecycle Manager (OLM).

The OADP Operator installs Velero 1.7.

Prerequisites

  • You must be logged in as a user with 
    cluster-admin
    privileges.

Procedure

  1. In the OpenShift Container Platform web console, click Operators OperatorHub.
  2. Use the Filter by keyword field to find the OADP Operator.
  3. Select the OADP Operator and click Install.
  4. Click Install to install the Operator in the 
    openshift-adp
    project.
  5. Click Operators Installed Operators to verify the installation.

4.2.3.2. Configuring Microsoft Azure Blob
Copiar enlace

You can configure a Microsoft Azure Blob storage container as a replication repository for the Migration Toolkit for Containers (MTC).

Prerequisites

  • You must have an Azure storage account.
  • You must have the Azure CLI installed.
  • The Azure Blob storage container must be accessible to the source and target clusters.

  • If you are using the snapshot copy method:

    • The source and target clusters must be in the same region.
    • The source and target clusters must have the same storage class.
    • The storage class must be compatible with snapshots.

Procedure

  1. Set the 

    AZURE_RESOURCE_GROUP
    variable: 

    $ AZURE_RESOURCE_GROUP=Velero_Backups

  2. Create an Azure resource group: 

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS>
    1
    1
    Specify your location.

  3. Set the 

    AZURE_STORAGE_ACCOUNT_ID
    variable: 

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups

  4. Create an Azure storage account: 

    $ az storage account create \
  --name $AZURE_STORAGE_ACCOUNT_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --sku Standard_GRS \
  --encryption-services blob \
  --https-only true \
  --kind BlobStorage \
  --access-tier Hot

  5. Set the 

    BLOB_CONTAINER
    variable: 

    $ BLOB_CONTAINER=velero

  6. Create an Azure Blob storage container: 

    $ az storage container create \
  -n $BLOB_CONTAINER \
  --public-access off \
  --account-name $AZURE_STORAGE_ACCOUNT_ID

  7. Obtain the storage account access key: 

    $ AZURE_STORAGE_ACCOUNT_ACCESS_KEY=`az storage account keys list \
  --account-name $AZURE_STORAGE_ACCOUNT_ID \
  --query "[?keyName == 'key1'].value" -o tsv`

  8. Create a 

    credentials-velero
    file: 

    $ cat << EOF > ./credentials-velero
AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
AZURE_TENANT_ID=${AZURE_TENANT_ID}
AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
AZURE_STORAGE_ACCOUNT_ACCESS_KEY=${AZURE_STORAGE_ACCOUNT_ACCESS_KEY}
    1 
    
AZURE_CLOUD_NAME=AzurePublicCloud
EOF
    1
    Mandatory. You cannot back up internal images if the credentials-velero file contains only the service principal credentials.

    You use the 

    credentials-velero
    file to create a 
    Secret
    object for Azure before you install the Data Protection Application.

4.2.3.3. Creating a secret for backup and snapshot locations
Copiar enlace

You create a 

Secret
object for the backup and snapshot locations if they use the same credentials.

The default name of the 

Secret
is 
cloud-credentials-azure
.

Prerequisites

  • Your object storage and cloud storage must use the same credentials.
  • You must configure object storage for Velero.

  • You must create a 

    credentials-velero
    file for the object storage in the appropriate format.

    Note

    The 

    DataProtectionApplication
    custom resource (CR) requires a 
    Secret
    for installation. If no 
    spec.backupLocations.credential.name
    value is specified, the default name is used.

    If you do not want to specify the backup locations or the snapshot locations, you must create a 

    Secret
    with the default name by using an empty 
    credentials-velero
    file.

Procedure

  • Create a 

    Secret
    with the default name: 

    $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero

The 

Secret
is referenced in the 
spec.backupLocations.credential
block of the 
DataProtectionApplication
CR when you install the Data Protection Application.

If your backup and snapshot locations use different credentials, you create two 

Secret
objects:

  • Backup location 
    Secret
    with a custom name. The custom name is specified in the 
    spec.backupLocations
    block of the 
    DataProtectionApplication
    custom resource (CR).
  • Snapshot location 
    Secret
    with the default name, 
    cloud-credentials-azure
    . This 
    Secret
    is not specified in the 
    DataProtectionApplication
    CR.

Procedure

  1. Create a 
    credentials-velero
    file for the snapshot location in the appropriate format for your cloud provider.

  2. Create a 

    Secret
    for the snapshot location with the default name: 

    $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
  3. Create a 
    credentials-velero
    file for the backup location in the appropriate format for your object storage.

  4. Create a 

    Secret
    for the backup location with a custom name: 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero

  5. Add the 

    Secret
    with the custom name to the 
    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
...
  backupLocations:
    - velero:
        config:
          resourceGroup: <azure_resource_group>
          storageAccount: <azure_storage_account_id>
          subscriptionId: <azure_subscription_id>
          storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
        credential:
          key: cloud
          name: <custom_secret>
    1 
    
        provider: azure
        default: true
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
  snapshotLocations:
    - velero:
        config:
          resourceGroup: <azure_resource_group>
          subscriptionId: <azure_subscription_id>
          incremental: "true"
        name: default
        provider: azure
    1
    Backup location Secret with custom name.

4.2.3.4. Configuring the Data Protection Application
Copiar enlace

You can configure Velero resource allocations and enable self-signed CA certificates.

4.2.3.4.1. Setting Velero CPU and memory resource allocations
Copiar enlace

You set the CPU and memory resource allocations for the 

Velero
pod by editing the 
DataProtectionApplication
custom resource (CR) manifest.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the values in the 

    spec.configuration.velero.podConfig.ResourceAllocations
    block of the 
    DataProtectionApplication
    CR manifest, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    1
    Specify the value in millicpus or CPU units. Default value is 500m or 1 CPU unit.
    2
    Default value is 512Mi.
    3
    Default value is 500m or 1 CPU unit.
    4
    Default value is 256Mi.
4.2.3.4.2. Enabling self-signed CA certificates
Copiar enlace

You must enable a self-signed CA certificate for object storage by editing the 

DataProtectionApplication
custom resource (CR) manifest to prevent a 
certificate signed by unknown authority
error.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the 

    spec.backupLocations.velero.objectStorage.caCert
    parameter and 
    spec.backupLocations.velero.config
    parameters of the 
    DataProtectionApplication
    CR manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    1
    Specify the Base46-encoded CA certificate string.
    2
    Must be false to disable SSL/TLS security.

4.2.3.5. Installing the Data Protection Application
Copiar enlace

You install the Data Protection Application (DPA) by creating an instance of the 

DataProtectionApplication
API.

Prerequisites

  • You must install the OADP Operator.
  • You must configure object storage as a backup location.
  • If you use snapshots to back up PVs, your cloud provider must support either a native snapshot API or Container Storage Interface (CSI) snapshots.
  • If the backup and snapshot locations use the same credentials, you must create a 
    Secret
    with the default name, 
    cloud-credentials-azure
    .

  • If the backup and snapshot locations use different credentials, you must create two 

    Secrets
    : 

    • Secret
      with a custom name for the backup location. You add this 
      Secret
      to the 
      DataProtectionApplication
      CR. 

    • Secret
      with the default name, 
      cloud-credentials-azure
      , for the snapshot location. This 
      Secret
      is not referenced in the 
      DataProtectionApplication
      CR.

      Note

      If you do not want to specify backup or snapshot locations during the installation, you can create a default 

      Secret
      with an empty 
      credentials-velero
      file. If there is no default 
      Secret
      , the installation will fail.

Procedure

  1. Click Operators Installed Operators and select the OADP Operator.
  2. Under Provided APIs, click Create instance in the DataProtectionApplication box.

  3. Click YAML View and update the parameters of the 

    DataProtectionApplication
    manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - azure
        - openshift
    1 
    
    restic:
      enable: true
    2 
    
  backupLocations:
    - velero:
        config:
          resourceGroup: <azure_resource_group>
    3 
    
          storageAccount: <azure_storage_account_id>
    4 
    
          subscriptionId: <azure_subscription_id>
    5 
    
          storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
        credential:
          key: cloud
          name: cloud-credentials-azure
    6 
    
        provider: azure
        default: true
        objectStorage:
          bucket: <bucket_name>
    7 
    
          prefix: <prefix>
    8 
    
  snapshotLocations:
    9 
    
    - velero:
        config:
          resourceGroup: <azure_resource_group>
          subscriptionId: <azure_subscription_id>
          incremental: "true"
        name: default
        provider: azure
    1
    The openshift plugin is mandatory in order to back up and restore namespaces on an OpenShift Container Platform cluster.
    2
    Set to false if you want to disable the Restic installation. Restic deploys a daemon set, which means that each worker node has Restic pods running. You configure Restic for backups by adding spec.defaultVolumesToRestic: true to the Backup CR.
    3
    Specify the Azure resource group.
    4
    Specify the Azure storage account ID.
    5
    Specify the Azure subscription ID.
    6
    If you do not specify this value, the default name, cloud-credentials-azure, is used. If you specify a custom name, the custom name is used for the backup location.
    7
    Specify a bucket as the backup storage location. If the bucket is not a dedicated bucket for Velero backups, you must specify a prefix.
    8
    Specify a prefix for Velero backups, for example, velero, if the bucket is used for multiple purposes.
    9
    You do not need to specify a snapshot location if you use CSI snapshots or Restic to back up PVs.
  4. Click Create.

  5. Verify the installation by viewing the OADP resources: 

    $ oc get all -n openshift-adp

    Example output

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s

4.2.3.5.1. Enabling CSI in the DataProtectionApplication CR
Copiar enlace

You enable the Container Storage Interface (CSI) in the 

DataProtectionApplication
custom resource (CR) in order to back up persistent volumes with CSI snapshots.

Prerequisites

  • The cloud provider must support CSI snapshots.

Procedure

  • Edit the 

    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    1
    Add the csi default plugin.
    2
    Add the EnableCSI feature flag.

You install the OpenShift API for Data Protection (OADP) with Google Cloud Platform (GCP) by installing the OADP Operator, configuring GCP for Velero, and then installing the Data Protection Application.

Important

The 

CloudStorage
API for S3 storage is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

To install the OADP Operator in a restricted network environment, you must first disable the default OperatorHub sources and mirror the Operator catalog. See Using Operator Lifecycle Manager on restricted networks for details.

4.2.4.1. Installing the OADP Operator
Copiar enlace

You install the OpenShift API for Data Protection (OADP) Operator on OpenShift Container Platform 4.8 by using Operator Lifecycle Manager (OLM).

The OADP Operator installs Velero 1.7.

Prerequisites

  • You must be logged in as a user with 
    cluster-admin
    privileges.

Procedure

  1. In the OpenShift Container Platform web console, click Operators OperatorHub.
  2. Use the Filter by keyword field to find the OADP Operator.
  3. Select the OADP Operator and click Install.
  4. Click Install to install the Operator in the 
    openshift-adp
    project.
  5. Click Operators Installed Operators to verify the installation.

4.2.4.2. Configuring Google Cloud Platform
Copiar enlace

You can configure a Google Cloud Platform (GCP) storage bucket as a replication repository for the Migration Toolkit for Containers (MTC).

Prerequisites

  • The GCP storage bucket must be accessible to the source and target clusters.
  • You must have gsutil installed.

  • If you are using the snapshot copy method:

    • The source and target clusters must be in the same region.
    • The source and target clusters must have the same storage class.
    • The storage class must be compatible with snapshots.

Procedure

  1. Log in to 

    gsutil
    : 

    $ gsutil init

    Example output

    Welcome! This command will take you through the configuration of gcloud.

Your current configuration has been set to: [default]

To continue, you must login. Would you like to login (Y/n)?

  2. Set the 

    BUCKET
    variable: 

    $ BUCKET=<bucket>
    1
    1
    Specify your bucket name.

  3. Create a storage bucket: 

    $ gsutil mb gs://$BUCKET/

  4. Set the 

    PROJECT_ID
    variable to your active project: 

    $ PROJECT_ID=`gcloud config get-value project`

  5. Create a 

    velero
    IAM service account: 

    $ gcloud iam service-accounts create velero \
    --display-name "Velero Storage"

  6. Create the 

    SERVICE_ACCOUNT_EMAIL
    variable: 

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
  --filter="displayName:Velero Storage" \
  --format 'value(email)'`

  7. Create the 

    ROLE_PERMISSIONS
    variable: 

    $ ROLE_PERMISSIONS=(
    compute.disks.get
    compute.disks.create
    compute.disks.createSnapshot
    compute.snapshots.get
    compute.snapshots.create
    compute.snapshots.useReadOnly
    compute.snapshots.delete
    compute.zones.get
)

  8. Create the 

    velero.server
    custom role: 

    $ gcloud iam roles create velero.server \
    --project $PROJECT_ID \
    --title "Velero Server" \
    --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"

  9. Add IAM policy binding to the project: 

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
    --role projects/$PROJECT_ID/roles/velero.server

  10. Update the IAM service account: 

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}

  11. Save the IAM service account keys to the 

    credentials-velero
    file in the current directory: 

    $ gcloud iam service-accounts keys create credentials-velero \
  --iam-account $SERVICE_ACCOUNT_EMAIL

    You use the 

    credentials-velero
    file to create a 
    Secret
    object for GCP before you install the Data Protection Application.

4.2.4.3. Creating a secret for backup and snapshot locations
Copiar enlace

You create a 

Secret
object for the backup and snapshot locations if they use the same credentials.

The default name of the 

Secret
is 
cloud-credentials-gcp
.

Prerequisites

  • Your object storage and cloud storage must use the same credentials.
  • You must configure object storage for Velero.
  • You must create a 
    credentials-velero
    file for the object storage in the appropriate format.

Procedure

  • Create a 

    Secret
    with the default name: 

    $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero

The 

Secret
is referenced in the 
spec.backupLocations.credential
block of the 
DataProtectionApplication
CR when you install the Data Protection Application.

If your backup and snapshot locations use different credentials, you create two 

Secret
objects:

  • Backup location 
    Secret
    with a custom name. The custom name is specified in the 
    spec.backupLocations
    block of the 
    DataProtectionApplication
    custom resource (CR).
  • Snapshot location 
    Secret
    with the default name, 
    cloud-credentials-gcp
    . This 
    Secret
    is not specified in the 
    DataProtectionApplication
    CR.

Procedure

  1. Create a 
    credentials-velero
    file for the snapshot location in the appropriate format for your cloud provider.

  2. Create a 

    Secret
    for the snapshot location with the default name: 

    $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
  3. Create a 
    credentials-velero
    file for the backup location in the appropriate format for your object storage.

  4. Create a 

    Secret
    for the backup location with a custom name: 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero

  5. Add the 

    Secret
    with the custom name to the 
    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
...
  backupLocations:
    - velero:
        provider: gcp
        default: true
        credential:
          key: cloud
          name: <custom_secret>
    1 
    
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
  snapshotLocations:
    - velero:
        provider: gcp
        default: true
        config:
          project: <project>
          snapshotLocation: us-west1
    1
    Backup location Secret with custom name.

4.2.4.4. Configuring the Data Protection Application
Copiar enlace

You can configure Velero resource allocations and enable self-signed CA certificates.

4.2.4.4.1. Setting Velero CPU and memory resource allocations
Copiar enlace

You set the CPU and memory resource allocations for the 

Velero
pod by editing the 
DataProtectionApplication
custom resource (CR) manifest.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the values in the 

    spec.configuration.velero.podConfig.ResourceAllocations
    block of the 
    DataProtectionApplication
    CR manifest, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    1
    Specify the value in millicpus or CPU units. Default value is 500m or 1 CPU unit.
    2
    Default value is 512Mi.
    3
    Default value is 500m or 1 CPU unit.
    4
    Default value is 256Mi.
4.2.4.4.2. Enabling self-signed CA certificates
Copiar enlace

You must enable a self-signed CA certificate for object storage by editing the 

DataProtectionApplication
custom resource (CR) manifest to prevent a 
certificate signed by unknown authority
error.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the 

    spec.backupLocations.velero.objectStorage.caCert
    parameter and 
    spec.backupLocations.velero.config
    parameters of the 
    DataProtectionApplication
    CR manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    1
    Specify the Base46-encoded CA certificate string.
    2
    Must be false to disable SSL/TLS security.

4.2.4.5. Installing the Data Protection Application
Copiar enlace

You install the Data Protection Application (DPA) by creating an instance of the 

DataProtectionApplication
API.

Prerequisites

  • You must install the OADP Operator.
  • You must configure object storage as a backup location.
  • If you use snapshots to back up PVs, your cloud provider must support either a native snapshot API or Container Storage Interface (CSI) snapshots.
  • If the backup and snapshot locations use the same credentials, you must create a 
    Secret
    with the default name, 
    cloud-credentials-gcp
    .

  • If the backup and snapshot locations use different credentials, you must create two 

    Secrets
    : 

    • Secret
      with a custom name for the backup location. You add this 
      Secret
      to the 
      DataProtectionApplication
      CR. 

    • Secret
      with the default name, 
      cloud-credentials-gcp
      , for the snapshot location. This 
      Secret
      is not referenced in the 
      DataProtectionApplication
      CR.

      Note

      If you do not want to specify backup or snapshot locations during the installation, you can create a default 

      Secret
      with an empty 
      credentials-velero
      file. If there is no default 
      Secret
      , the installation will fail.

Procedure

  1. Click Operators Installed Operators and select the OADP Operator.
  2. Under Provided APIs, click Create instance in the DataProtectionApplication box.

  3. Click YAML View and update the parameters of the 

    DataProtectionApplication
    manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - gcp
        - openshift
    1 
    
    restic:
      enable: true
    2 
    
  backupLocations:
    - velero:
        provider: gcp
        default: true
        credential:
          key: cloud
          name: cloud-credentials-gcp
    3 
    
        objectStorage:
          bucket: <bucket_name>
    4 
    
          prefix: <prefix>
    5 
    
  snapshotLocations:
    6 
    
    - velero:
        provider: gcp
        default: true
        config:
          project: <project>
          snapshotLocation: us-west1
    7
    1
    The openshift plugin is mandatory in order to back up and restore namespaces on an OpenShift Container Platform cluster.
    2
    Set to false if you want to disable the Restic installation. Restic deploys a daemon set, which means that each worker node has Restic pods running. You configure Restic for backups by adding spec.defaultVolumesToRestic: true to the Backup CR.
    3
    If you do not specify this value, the default name, cloud-credentials-gcp, is used. If you specify a custom name, the custom name is used for the backup location.
    4
    Specify a bucket as the backup storage location. If the bucket is not a dedicated bucket for Velero backups, you must specify a prefix.
    5
    Specify a prefix for Velero backups, for example, velero, if the bucket is used for multiple purposes.
    6
    You do not need to specify a snapshot location if you use CSI snapshots or Restic to back up PVs.
    7
    The snapshot location must be in the same region as the PVs.
  4. Click Create.

  5. Verify the installation by viewing the OADP resources: 

    $ oc get all -n openshift-adp

    Example output

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s

4.2.4.5.1. Enabling CSI in the DataProtectionApplication CR
Copiar enlace

You enable the Container Storage Interface (CSI) in the 

DataProtectionApplication
custom resource (CR) in order to back up persistent volumes with CSI snapshots.

Prerequisites

  • The cloud provider must support CSI snapshots.

Procedure

  • Edit the 

    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    1
    Add the csi default plugin.
    2
    Add the EnableCSI feature flag.

You install the OpenShift API for Data Protection (OADP) with Multicloud Object Gateway (MCG) by installing the OADP Operator, creating a 

Secret
object, and then installing the Data Protection Application.

MCG is a component of OpenShift Container Storage (OCS). You configure MCG as a backup location in the 

DataProtectionApplication
custom resource (CR).

Important

The 

CloudStorage
API for S3 storage is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

If your cloud provider has a native snapshot API, configure a snapshot location. If your cloud provider does not support snapshots or if your storage is NFS, you can create backups with Restic.

You do not need to specify a snapshot location in the 

DataProtectionApplication
CR for Restic or Container Storage Interface (CSI) snapshots.

To install the OADP Operator in a restricted network environment, you must first disable the default OperatorHub sources and mirror the Operator catalog. For details, see Using Operator Lifecycle Manager on restricted networks.

4.2.5.1. Installing the OADP Operator
Copiar enlace

You install the OpenShift API for Data Protection (OADP) Operator on OpenShift Container Platform 4.8 by using Operator Lifecycle Manager (OLM).

The OADP Operator installs Velero 1.7.

Prerequisites

  • You must be logged in as a user with 
    cluster-admin
    privileges.

Procedure

  1. In the OpenShift Container Platform web console, click Operators OperatorHub.
  2. Use the Filter by keyword field to find the OADP Operator.
  3. Select the OADP Operator and click Install.
  4. Click Install to install the Operator in the 
    openshift-adp
    project.
  5. Click Operators Installed Operators to verify the installation.

4.2.5.2. Configuring Multi-Cloud Object Gateway
Copiar enlace

You can install the OpenShift Container Storage Operator and configure a Multi-Cloud Object Gateway (MCG) storage bucket as a replication repository for the Migration Toolkit for Containers (MTC).

4.2.5.2.1. Installing the OpenShift Container Storage Operator
Copiar enlace

You can install the OpenShift Container Storage Operator from OperatorHub.

Procedure

  1. In the OpenShift Container Platform web console, click Operators OperatorHub.
  2. Use Filter by keyword (in this case, OCS) to find the OpenShift Container Storage Operator.
  3. Select the OpenShift Container Storage Operator and click Install.
  4. Select an Update Channel, Installation Mode, and Approval Strategy.

  5. Click Install.

    On the Installed Operators page, the OpenShift Container Storage Operator appears in the openshift-storage project with the status Succeeded.

4.2.5.2.2. Creating the Multi-Cloud Object Gateway storage bucket
Copiar enlace

You can create the Multi-Cloud Object Gateway (MCG) storage bucket’s custom resources (CRs).

Procedure

  1. Log in to the OpenShift Container Platform cluster: 

    $ oc login -u <username>

  2. Create the 

    NooBaa
    CR configuration file, 
    noobaa.yml
    , with the following content: 

    apiVersion: noobaa.io/v1alpha1
kind: NooBaa
metadata:
  name: <noobaa>
  namespace: openshift-storage
spec:
 dbResources:
   requests:
     cpu: 0.5
    1 
    
     memory: 1Gi
 coreResources:
   requests:
     cpu: 0.5
    2 
    
     memory: 1Gi
    1 2
    For a very small cluster, you can change the value to 0.1.

  3. Create the 

    NooBaa
    object: 

    $ oc create -f noobaa.yml

  4. Create the 

    BackingStore
    CR configuration file, 
    bs.yml
    , with the following content: 

    apiVersion: noobaa.io/v1alpha1
kind: BackingStore
metadata:
  finalizers:
  - noobaa.io/finalizer
  labels:
    app: noobaa
  name: <mcg_backing_store>
  namespace: openshift-storage
spec:
  pvPool:
    numVolumes: 3
    1 
    
    resources:
      requests:
        storage: <volume_size>
    2 
    
    storageClass: <storage_class>
    3 
    
  type: pv-pool
    1
    Specify the number of volumes in the persistent volume pool.
    2
    Specify the size of the volumes, for example, 50Gi.
    3
    Specify the storage class, for example, gp2.

  5. Create the 

    BackingStore
    object: 

    $ oc create -f bs.yml

  6. Create the 

    BucketClass
    CR configuration file, 
    bc.yml
    , with the following content: 

    apiVersion: noobaa.io/v1alpha1
kind: BucketClass
metadata:
  labels:
    app: noobaa
  name: <mcg_bucket_class>
  namespace: openshift-storage
spec:
  placementPolicy:
    tiers:
    - backingStores:
      - <mcg_backing_store>
      placement: Spread

  7. Create the 

    BucketClass
    object: 

    $ oc create -f bc.yml

  8. Create the 

    ObjectBucketClaim
    CR configuration file, 
    obc.yml
    , with the following content: 

    apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: <bucket>
  namespace: openshift-storage
spec:
  bucketName: <bucket>
    1 
    
  storageClassName: <storage_class>
  additionalConfig:
    bucketclass: <mcg_bucket_class>
    1
    Record the bucket name for adding the replication repository to the MTC web console.

  9. Create the 

    ObjectBucketClaim
    object: 

    $ oc create -f obc.yml

  10. Watch the resource creation process to verify that the 

    ObjectBucketClaim
    status is 
    Bound
    : 

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    This process can take five to ten minutes.

  11. Obtain and record the following values, which are required when you add the replication repository to the MTC web console:

    • S3 endpoint: 

      $ oc get route -n openshift-storage s3

    • S3 provider access key: 

      $ oc get secret -n openshift-storage migstorage \
  -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode

    • S3 provider secret access key: 

      $ oc get secret -n openshift-storage migstorage \
  -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

4.2.5.3. Creating a secret for backup and snapshot locations
Copiar enlace

You create a 

Secret
object for the backup and snapshot locations if they use the same credentials.

The default name of the 

Secret
is 
cloud-credentials
.

Prerequisites

  • Your object storage and cloud storage must use the same credentials.
  • You must configure object storage for Velero.
  • You must create a 
    credentials-velero
    file for the object storage in the appropriate format.

Procedure

  • Create a 

    Secret
    with the default name: 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

The 

Secret
is referenced in the 
spec.backupLocations.credential
block of the 
DataProtectionApplication
CR when you install the Data Protection Application.

If your backup and snapshot locations use different credentials, you create two 

Secret
objects:

  • Backup location 
    Secret
    with a custom name. The custom name is specified in the 
    spec.backupLocations
    block of the 
    DataProtectionApplication
    custom resource (CR).
  • Snapshot location 
    Secret
    with the default name, 
    cloud-credentials
    . This 
    Secret
    is not specified in the 
    DataProtectionApplication
    CR.

Procedure

  1. Create a 
    credentials-velero
    file for the snapshot location in the appropriate format for your cloud provider.

  2. Create a 

    Secret
    for the snapshot location with the default name: 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
  3. Create a 
    credentials-velero
    file for the backup location in the appropriate format for your object storage.

  4. Create a 

    Secret
    for the backup location with a custom name: 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero

  5. Add the 

    Secret
    with the custom name to the 
    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - aws
        - openshift
    restic:
      enable: true
  backupLocations:
    - velero:
        config:
          profile: "default"
          region: minio
          s3Url: <url>
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: aws
        default: true
        credential:
          key: cloud
          name:  <custom_secret>
    1 
    
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
    1
    Backup location Secret with custom name.

4.2.5.4. Configuring the Data Protection Application
Copiar enlace

You can configure Velero resource allocations and enable self-signed CA certificates.

4.2.5.4.1. Setting Velero CPU and memory resource allocations
Copiar enlace

You set the CPU and memory resource allocations for the 

Velero
pod by editing the 
DataProtectionApplication
custom resource (CR) manifest.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the values in the 

    spec.configuration.velero.podConfig.ResourceAllocations
    block of the 
    DataProtectionApplication
    CR manifest, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    1
    Specify the value in millicpus or CPU units. Default value is 500m or 1 CPU unit.
    2
    Default value is 512Mi.
    3
    Default value is 500m or 1 CPU unit.
    4
    Default value is 256Mi.
4.2.5.4.2. Enabling self-signed CA certificates
Copiar enlace

You must enable a self-signed CA certificate for object storage by editing the 

DataProtectionApplication
custom resource (CR) manifest to prevent a 
certificate signed by unknown authority
error.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the 

    spec.backupLocations.velero.objectStorage.caCert
    parameter and 
    spec.backupLocations.velero.config
    parameters of the 
    DataProtectionApplication
    CR manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    1
    Specify the Base46-encoded CA certificate string.
    2
    Must be false to disable SSL/TLS security.

4.2.5.5. Installing the Data Protection Application
Copiar enlace

You install the Data Protection Application (DPA) by creating an instance of the 

DataProtectionApplication
API.

Prerequisites

  • You must install the OADP Operator.
  • You must configure object storage as a backup location.
  • If you use snapshots to back up PVs, your cloud provider must support either a native snapshot API or Container Storage Interface (CSI) snapshots.
  • If the backup and snapshot locations use the same credentials, you must create a 
    Secret
    with the default name, 
    cloud-credentials
    .

  • If the backup and snapshot locations use different credentials, you must create two 

    Secrets
    : 

    • Secret
      with a custom name for the backup location. You add this 
      Secret
      to the 
      DataProtectionApplication
      CR. 

    • Secret
      with the default name, 
      cloud-credentials
      , for the snapshot location. This 
      Secret
      is not referenced in the 
      DataProtectionApplication
      CR.

      Note

      If you do not want to specify backup or snapshot locations during the installation, you can create a default 

      Secret
      with an empty 
      credentials-velero
      file. If there is no default 
      Secret
      , the installation will fail.

Procedure

  1. Click Operators Installed Operators and select the OADP Operator.
  2. Under Provided APIs, click Create instance in the DataProtectionApplication box.

  3. Click YAML View and update the parameters of the 

    DataProtectionApplication
    manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - aws
        - openshift
    1 
    
    restic:
      enable: true
    2 
    
  backupLocations:
    - velero:
        config:
          profile: "default"
          region: minio
          s3Url: <url>
    3 
    
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: aws
        default: true
        credential:
          key: cloud
          name: cloud-credentials
    4 
    
        objectStorage:
          bucket: <bucket_name>
    5 
    
          prefix: <prefix>
    6
    1
    The openshift plugin is mandatory in order to back up and restore namespaces on an OpenShift Container Platform cluster.
    2
    Set to false if you want to disable the Restic installation. Restic deploys a daemon set, which means that each worker node has Restic pods running. You configure Restic for backups by adding spec.defaultVolumesToRestic: true to the Backup CR.
    3
    Specify the URL of the S3 endpoint.
    4
    If you do not specify this value, the default name, cloud-credentials, is used. If you specify a custom name, the custom name is used for the backup location.
    5
    Specify a bucket as the backup storage location. If the bucket is not a dedicated bucket for Velero backups, you must specify a prefix.
    6
    Specify a prefix for Velero backups, for example, velero, if the bucket is used for multiple purposes.
  4. Click Create.

  5. Verify the installation by viewing the OADP resources: 

    $ oc get all -n openshift-adp

    Example output

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s

4.2.5.5.1. Enabling CSI in the DataProtectionApplication CR
Copiar enlace

You enable the Container Storage Interface (CSI) in the 

DataProtectionApplication
custom resource (CR) in order to back up persistent volumes with CSI snapshots.

Prerequisites

  • The cloud provider must support CSI snapshots.

Procedure

  • Edit the 

    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    1
    Add the csi default plugin.
    2
    Add the EnableCSI feature flag.

You install the OpenShift API for Data Protection (OADP) with OpenShift Container Storage (OCS) by installing the OADP Operator and configuring a backup location and a snapshot location. Then, you install the Data Protection Application.

You can configure Multicloud Object Gateway or any S3-compatible object storage as a backup location in the 

DataProtectionApplication
custom resource (CR).

Important

The 

CloudStorage
API for S3 storage is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

If the cloud provider has a native snapshot API, you can configure cloud storage as a snapshot location in the 

DataProtectionApplication
CR. You do not need to specify a snapshot location for Restic or Container Storage Interface (CSI) snapshots.

To install the OADP Operator in a restricted network environment, you must first disable the default OperatorHub sources and mirror the Operator catalog. For details, see Using Operator Lifecycle Manager on restricted networks.

4.2.6.1. Installing the OADP Operator
Copiar enlace

You install the OpenShift API for Data Protection (OADP) Operator on OpenShift Container Platform 4.8 by using Operator Lifecycle Manager (OLM).

The OADP Operator installs Velero 1.7.

Prerequisites

  • You must be logged in as a user with 
    cluster-admin
    privileges.

Procedure

  1. In the OpenShift Container Platform web console, click Operators OperatorHub.
  2. Use the Filter by keyword field to find the OADP Operator.
  3. Select the OADP Operator and click Install.
  4. Click Install to install the Operator in the 
    openshift-adp
    project.
  5. Click Operators Installed Operators to verify the installation.
Note

After you install the OADP Operator, you configure object storage as a backup location and cloud storage as a snapshot location, if the cloud provider supports a native snapshot API.

If the cloud provider does not support snapshots or if your storage is NFS, you can create backups with Restic. Restic does not require a snapshot location.

4.2.6.2. Creating a secret for backup and snapshot locations
Copiar enlace

You create a 

Secret
object for the backup and snapshot locations if they use the same credentials.

The default name of the 

Secret
is 
cloud-credentials
, unless you specify a default plugin for the backup storage provider.

Prerequisites

  • Your object storage and cloud storage must use the same credentials.
  • You must configure object storage for Velero.
  • You must create a 
    credentials-velero
    file for the object storage in the appropriate format.

Procedure

  • Create a 

    Secret
    with the default name: 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

The 

Secret
is referenced in the 
spec.backupLocations.credential
block of the 
DataProtectionApplication
CR when you install the Data Protection Application.

If your backup and snapshot locations use different credentials, you create two 

Secret
objects:

  • Backup location 
    Secret
    with a custom name. The custom name is specified in the 
    spec.backupLocations
    block of the 
    DataProtectionApplication
    custom resource (CR).
  • Snapshot location 
    Secret
    with the default name, 
    cloud-credentials
    . This 
    Secret
    is not specified in the 
    DataProtectionApplication
    CR.

Procedure

  1. Create a 
    credentials-velero
    file for the snapshot location in the appropriate format for your cloud provider.

  2. Create a 

    Secret
    for the snapshot location with the default name: 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
  3. Create a 
    credentials-velero
    file for the backup location in the appropriate format for your object storage.

  4. Create a 

    Secret
    for the backup location with a custom name: 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero

  5. Add the 

    Secret
    with the custom name to the 
    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - csi
        - openshift
    featureFlags:
    - EnableCSI
    restic:
      enable: true
  backupLocations:
    - velero:
        provider: gcp
        default: true
        credential:
          key: cloud
          name: <custom_secret>
    1 
    
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
    1
    Backup location Secret with custom name.

4.2.6.3. Configuring the Data Protection Application
Copiar enlace

You can configure Velero resource allocations and enable self-signed CA certificates.

4.2.6.3.1. Setting Velero CPU and memory resource allocations
Copiar enlace

You set the CPU and memory resource allocations for the 

Velero
pod by editing the 
DataProtectionApplication
custom resource (CR) manifest.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the values in the 

    spec.configuration.velero.podConfig.ResourceAllocations
    block of the 
    DataProtectionApplication
    CR manifest, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    1
    Specify the value in millicpus or CPU units. Default value is 500m or 1 CPU unit.
    2
    Default value is 512Mi.
    3
    Default value is 500m or 1 CPU unit.
    4
    Default value is 256Mi.
4.2.6.3.2. Enabling self-signed CA certificates
Copiar enlace

You must enable a self-signed CA certificate for object storage by editing the 

DataProtectionApplication
custom resource (CR) manifest to prevent a 
certificate signed by unknown authority
error.

Prerequisites

  • You must have the OpenShift API for Data Protection (OADP) Operator installed.

Procedure

  • Edit the 

    spec.backupLocations.velero.objectStorage.caCert
    parameter and 
    spec.backupLocations.velero.config
    parameters of the 
    DataProtectionApplication
    CR manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    1
    Specify the Base46-encoded CA certificate string.
    2
    Must be false to disable SSL/TLS security.

4.2.6.4. Installing the Data Protection Application
Copiar enlace

You install the Data Protection Application (DPA) by creating an instance of the 

DataProtectionApplication
API.

Prerequisites

  • You must install the OADP Operator.
  • You must configure object storage as a backup location.
  • If you use snapshots to back up PVs, your cloud provider must support either a native snapshot API or Container Storage Interface (CSI) snapshots.
  • If the backup and snapshot locations use the same credentials, you must create a 
    Secret
    with the default name, 
    cloud-credentials
    .

  • If the backup and snapshot locations use different credentials, you must create two 

    Secrets
    : 

    • Secret
      with a custom name for the backup location. You add this 
      Secret
      to the 
      DataProtectionApplication
      CR. 

    • Secret
      with the default name, 
      cloud-credentials
      , for the snapshot location. This 
      Secret
      is not referenced in the 
      DataProtectionApplication
      CR.

      Note

      If you do not want to specify backup or snapshot locations during the installation, you can create a default 

      Secret
      with an empty 
      credentials-velero
      file. If there is no default 
      Secret
      , the installation will fail.

Procedure

  1. Click Operators Installed Operators and select the OADP Operator.
  2. Under Provided APIs, click Create instance in the DataProtectionApplication box.

  3. Click YAML View and update the parameters of the 

    DataProtectionApplication
    manifest: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - gcp <.>
        - csi <.>
        - openshift
    1 
    
    restic:
      enable: true
    2 
    
  backupLocations:
    - velero:
        provider: gcp
    3 
    
        default: true
        credential:
          key: cloud
          name: <default_secret>
    4 
    
        objectStorage:
          bucket: <bucket_name>
    5 
    
          prefix: <prefix>
    6
    1
    Specify the default plugin for the backup provider, for example, gcp, if appropriate.
    2
    Specify the csi default plugin if you use CSI snapshots to back up PVs. The csi plugin uses the Velero CSI beta snapshot APIs. You do not need to configure a snapshot location.
    3
    The openshift plugin is mandatory in order to back up and restore namespaces on an OpenShift Container Platform cluster.
    4
    Set to false if you want to disable the Restic installation. Restic deploys a daemon set, which means that each worker node has Restic pods running. You configure Restic for backups by adding spec.defaultVolumesToRestic: true to the Backup CR.
    5
    Specify the backup provider.
    6
    If you use a default plugin for the backup provider, you must specify the correct default name for the Secret, for example, cloud-credentials-gcp. If you specify a custom name, the custom name is used for the backup location. If you do not specify a Secret name, the default name is used.
    Specify a bucket as the backup storage location. If the bucket is not a dedicated bucket for Velero backups, you must specify a prefix.
    Specify a prefix for Velero backups, for example, velero, if the bucket is used for multiple purposes.
  4. Click Create.

  5. Verify the installation by viewing the OADP resources: 

    $ oc get all -n openshift-adp

    Example output

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s

4.2.6.4.1. Enabling CSI in the DataProtectionApplication CR
Copiar enlace

You enable the Container Storage Interface (CSI) in the 

DataProtectionApplication
custom resource (CR) in order to back up persistent volumes with CSI snapshots.

Prerequisites

  • The cloud provider must support CSI snapshots.

Procedure

  • Edit the 

    DataProtectionApplication
    CR, as in the following example: 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    1
    Add the csi default plugin.
    2
    Add the EnableCSI feature flag.

4.2.7. Uninstalling the OpenShift API for Data Protection
Copiar enlace

You uninstall the OpenShift API for Data Protection (OADP) by deleting the OADP Operator. See Deleting Operators from a cluster for details.

4.3. Backing up and restoring
Copiar enlace

4.3.1. Backing up applications
Copiar enlace

You back up applications by creating a Backup custom resource (CR).

The 

Backup
CR creates backup files for Kubernetes resources and internal images, on S3 object storage, and snapshots for persistent volumes (PVs), if the cloud provider uses a native snapshot API or the Container Storage Interface (CSI) to create snapshots, such as OpenShift Container Storage 4. For more information, see CSI volume snapshots.

Important

The 

CloudStorage
API for S3 storage is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

If your cloud provider has a native snapshot API or supports Container Storage Interface (CSI) snapshots, the 

Backup
CR backs up persistent volumes by creating snapshots. For more information, see the Overview of CSI volume snapshots in the OpenShift Container Platform documentation.

If your cloud provider does not support snapshots or if your applications are on NFS data volumes, you can create backups by using Restic.

You can create backup hooks to run commands before or after the backup operation.

You can schedule backups by creating a Schedule CR instead of a 

Backup
CR.

4.3.1.1. Creating a Backup CR
Copiar enlace

You back up Kubernetes images, internal images, and persistent volumes (PVs) by creating a 

Backup
custom resource (CR).

Prerequisites

  • You must install the OpenShift API for Data Protection (OADP) Operator.
  • The 
    DataProtectionApplication
    CR must be in a 
    Ready
    state.

  • Backup location prerequisites:

    • You must have S3 object storage configured for Velero.
    • You must have a backup location configured in the 
      DataProtectionApplication
      CR.

  • Snapshot location prerequisites:

    • Your cloud provider must have a native snapshot API or support Container Storage Interface (CSI) snapshots.
    • For CSI snapshots, you must create a 
      VolumeSnapshotClass
      CR to register the CSI driver.
    • You must have a volume location configured in the 
      DataProtectionApplication
      CR.

Procedure

  1. Retrieve the 

    backupStorageLocations
    CRs: 

    $ oc get backupStorageLocations

    Example output

    NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
velero-sample-1   Available   11s              31m

  2. Create a 

    Backup
    CR, as in the following example: 

    apiVersion: velero.io/v1
kind: Backup
metadata:
  name: <backup>
  labels:
    velero.io/storage-location: default
  namespace: openshift-adp
spec:
  hooks: {}
  includedNamespaces:
  - <namespace>
    1 
    
  storageLocation: <velero-sample-1>
    2 
    
  ttl: 720h0m0s
    1
    Specify an array of namespaces to back up.
    2
    Specify the name of the backupStorageLocations CR.

  3. Verify that the status of the 

    Backup
    CR is 
    Completed
    : 

    $ oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'

4.3.1.2. Backing up persistent volumes with CSI snapshots
Copiar enlace

You back up persistent volumes with Container Storage Interface (CSI) snapshots by creating a 

VolumeSnapshotClass
custom resource (CR) to register the CSI driver before you create the 
Backup
CR.

Prerequisites

  • The cloud provider must support CSI snapshots.
  • You must enable CSI in the 
    DataProtectionApplication
    CR.

Procedure

  • Create a 

    VolumeSnapshotClass
    CR, as in the following examples:

    Ceph RBD

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
deletionPolicy: Retain
metadata:
  name: <volume_snapshot_class_name>
  labels:
    velero.io/csi-volumesnapshot-class: "true"
    snapshotter: openshift-storage.rbd.csi.ceph.com
driver: openshift-storage.rbd.csi.ceph.com
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/snapshotter-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/snapshotter-secret-namespace: openshift-storage

    Ceph FS

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: <volume_snapshot_class_name>
  labels:
    velero.io/csi-volumesnapshot-class: "true"
driver: openshift-storage.cephfs.csi.ceph.com
deletionPolicy: Retain
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/snapshotter-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/snapshotter-secret-namespace: openshift-storage

    Other cloud providers

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: <volume_snapshot_class_name>
  labels:
    velero.io/csi-volumesnapshot-class: "true"
driver: <csi_driver>
deletionPolicy: Retain

You can now create a 

Backup
CR.

4.3.1.3. Backing up applications with Restic
Copiar enlace

You back up Kubernetes resources, internal images, and persistent volumes with Restic by editing the 

Backup
custom resource (CR).

You do not need to specify a snapshot location in the 

DataProtectionApplication
CR.

Prerequisites

  • You must install the OpenShift API for Data Protection (OADP) Operator.
  • You must not disable the default Restic installation by setting 
    spec.configuration.restic.enable
    to 
    false
    in the 
    DataProtectionApplication
    CR.
  • The 
    DataProtectionApplication
    CR must be in a 
    Ready
    state.

Procedure

  • Edit the 

    Backup
    CR, as in the following example: 

    apiVersion: velero.io/v1
kind: Backup
metadata:
  name: <backup>
  labels:
    velero.io/storage-location: default
  namespace: openshift-adp
spec:
  defaultVolumesToRestic: true
    1 
    
...
    1
    Add defaultVolumesToRestic: true to the spec block.

4.3.1.4. Creating backup hooks
Copiar enlace

You create backup hooks to run commands in a container in a pod by editing the 

Backup
custom resource (CR).

Pre hooks run before the pod is backed up. Post hooks run after the backup.

Procedure

  • Add a hook to the 

    spec.hooks
    block of the 
    Backup
    CR, as in the following example: 

    apiVersion: velero.io/v1
kind: Backup
metadata:
  name: <backup>
  namespace: openshift-adp
spec:
  hooks:
    resources:
      - name: <hook_name>
        includedNamespaces:
        - <namespace>
    1 
    
        excludedNamespaces:
        - <namespace>
        includedResources:
        - pods
    2 
    
        excludedResources: []
        labelSelector:
    3 
    
          matchLabels:
            app: velero
            component: server
        pre:
    4 
    
          - exec:
              container: <container>
    5 
    
              command:
              - /bin/uname
    6 
    
              - -a
              onError: Fail
    7 
    
              timeout: 30s
    8 
    
        post:
    9 
    
...
    1
    Array of namespaces to which the hook applies. If this value is not specified, the hook applies to all namespaces.
    2
    Currently, pods are the only supported resource.
    3
    Optional: This hook only applies to objects matching the label selector.
    4
    Array of hooks to run before the backup.
    5
    Optional: If the container is not specified, the command runs in the first container in the pod.
    6
    Array of commands that the hook runs.
    7
    Allowed values for error handling are Fail and Continue. The default is Fail.
    8
    Optional: How long to wait for the commands to run. The default is 30s.
    9
    This block defines an array of hooks to run after the backup, with the same parameters as the pre-backup hooks.

4.3.1.5. Scheduling backups
Copiar enlace

You schedule backups by creating a 

Schedule
custom resource (CR) instead of a 
Backup
CR.

Warning

Leave enough time in your backup schedule for a backup to finish before another backup is created.

For example, if a backup of a namespace typically takes 10 minutes, do not schedule backups more frequently than every 15 minutes.

Prerequisites

  • You must install the OpenShift API for Data Protection (OADP) Operator.
  • The 
    DataProtectionApplication
    CR must be in a 
    Ready
    state.

Procedure

  1. Retrieve the 

    backupStorageLocations
    CRs: 

    $ oc get backupStorageLocations

    Example output

    NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
velero-sample-1   Available   11s              31m

  2. Create a 

    Schedule
    CR, as in the following example: 

    $ cat << EOF | oc apply -f -
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: <schedule>
  namespace: openshift-adp
spec:
  schedule: 0 7 * * *
    1 
    
  template:
    hooks: {}
    includedNamespaces:
    - <namespace>
    2 
    
    storageLocation: <velero-sample-1>
    3 
    
    defaultVolumesToRestic: true
    4 
    
    ttl: 720h0m0s
EOF
    1
    cron expression to schedule the backup, for example, 0 7 * * * to perform a backup every day at 7:00.
    2
    Array of namespaces to back up.
    3
    Name of the backupStorageLocations CR.
    4
    Optional: Add the defaultVolumesToRestic: true key-value pair if you are backing up volumes with Restic.

  3. Verify that the status of the 

    Schedule
    CR is 
    Completed
    after the scheduled backup runs: 

    $ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'

4.3.2. Restoring applications
Copiar enlace

You restore application backups by creating a Restore custom resources (CRs).

You can create restore hooks to run commands in init containers, before the application container starts, or in the application container itself.

4.3.2.1. Creating a Restore CR
Copiar enlace

You restore a 

Backup
custom resource (CR) by creating a 
Restore
CR.

Prerequisites

  • You must install the OpenShift API for Data Protection (OADP) Operator.
  • The 
    DataProtectionApplication
    CR must be in a 
    Ready
    state.
  • You must have a Velero 
    Backup
    CR.
  • Adjust the requested size so the persistent volume (PV) capacity matches the requested size at backup time.

Procedure

  1. Create a 

    Restore
    CR, as in the following example: 

    apiVersion: velero.io/v1
kind: Restore
metadata:
  name: <restore>
  namespace: openshift-adp
spec:
  backupName: <backup>
    1 
    
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  restorePVs: true
    1
    Name of the Backup CR.

  2. Verify that the status of the 

    Restore
    CR is 
    Completed
    : 

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'

  3. Verify that the backup resources have been restored: 

    $ oc get all -n <namespace>
    1
    1
    Namespace that you backed up.

4.3.2.2. Creating restore hooks
Copiar enlace

You create restore hooks to run commands in a container in a pod while restoring your application by editing the 

Restore
custom resource (CR).

You can create two types of restore hooks:

  • An 

    init
    hook adds an init container to a pod to perform setup tasks before the application container starts.

    If you restore a Restic backup, the 

    restic-wait
    init container is added before the restore hook init container.

  • An 
    exec
    hook runs commands or scripts in a container of a restored pod.

Procedure

  • Add a hook to the 

    spec.hooks
    block of the 
    Restore
    CR, as in the following example: 

    apiVersion: velero.io/v1
kind: Restore
metadata:
  name: <restore>
  namespace: openshift-adp
spec:
  hooks:
    resources:
      - name: <hook_name>
        includedNamespaces:
        - <namespace>
    1 
    
        excludedNamespaces:
        - <namespace>
        includedResources:
        - pods
    2 
    
        excludedResources: []
        labelSelector:
    3 
    
          matchLabels:
            app: velero
            component: server
        postHooks:
        - init:
            initContainers:
            - name: restore-hook-init
              image: alpine:latest
              volumeMounts:
              - mountPath: /restores/pvc1-vm
                name: pvc1-vm
              command:
              - /bin/ash
              - -c
        - exec:
            container: <container>
    4 
    
            command:
            - /bin/bash
    5 
    
            - -c
            - "psql < /backup/backup.sql"
            waitTimeout: 5m
    6 
    
            execTimeout: 1m
    7 
    
            onError: Continue
    8
    1
    Optional: Array of namespaces to which the hook applies. If this value is not specified, the hook applies to all namespaces.
    2
    Currently, pods are the only supported resource.
    3
    Optional: This hook only applies to objects matching the label selector.
    4
    Optional: If the container is not specified, the command runs in the first container in the pod.
    5
    Array of commands that the hook runs.
    6
    Optional: If the waitTimeout is not specified, the restore waits indefinitely. You can specify how long to wait for a container to start and for preceding hooks in the container to complete. The wait timeout starts when the container is restored and might require time for the container to pull the image and mount the volumes.
    7
    Optional: How long to wait for the commands to run. The default is 30s.
    8
    Allowed values for error handling are Fail and Continue: 
    • Continue
      : Only command failures are logged. 
    • Fail
      : No more restore hooks run in any container in any pod. The status of the 
      Restore
      CR will be 
      PartiallyFailed
      .

4.4. Troubleshooting
Copiar enlace

You can debug Velero custom resources (CRs) by using the OpenShift CLI tool or the Velero CLI tool. The Velero CLI tool provides more detailed logs and information.

You can check installation issues, backup and restore CR issues, and Restic issues.

You can collect logs, CR information, and Prometheus metric data by using the must-gather tool.

You can obtain the Velero CLI tool by:

  • Downloading the Velero CLI tool
  • Accessing the Velero binary in the Velero deployment in the cluster

4.4.1. Downloading the Velero CLI tool
Copiar enlace

You can download and install the Velero CLI tool by following the instructions on the Velero documentation page.

The page includes instructions for:

  • macOS by using Homebrew
  • GitHub
  • Windows by using Chocolatey

Prerequisites

  • You have access to a Kubernetes cluster, v1.16 or later, with DNS and container networking enabled.
  • You have installed 
    kubectl
    locally.

Procedure

  1. Open a browser and navigate to "Install the CLI" on the Verleo website.
  2. Follow the appropriate procedure for macOS, GitHub, or Windows.

  3. Download the Velero version appropriate for your version of OADP, according to the table that follows:

    Expand
    Table 4.2. OADP-Velero version relationship
    OADP versionVelero version

    0.2.6

    1.6.0

    0.5.5

    1.7.1

    1.0.0

    1.7.1

    1.0.1

    1.7.1

    1.0.2

    1.7.1

    1.0.3

    1.7.1

You can use a shell command to access the Velero binary in the Velero deployment in the cluster.

Prerequisites

  • Your 
    DataProtectionApplication
    custom resource has a status of 
    Reconcile complete
    .

Procedure

  • Enter the following command to set the needed alias: 

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'

4.4.3. Debugging Velero resources with the OpenShift CLI tool
Copiar enlace

You can debug a failed backup or restore by checking Velero custom resources (CRs) and the 

Velero
pod log with the OpenShift CLI tool.

Velero CRs

Use the 

oc describe
command to retrieve a summary of warnings and errors associated with a 
Backup
or 
Restore
CR: 

$ oc describe <velero_cr> <cr_name>
Velero pod logs

Use the 

oc logs
command to retrieve the 
Velero
pod logs: 

$ oc logs pod/<velero>
Velero pod debug logs

You can specify the Velero log level in the 

DataProtectionApplication
resource as shown in the following example.

Note

This option is available starting from OADP 1.0.3. 

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
spec:
  configuration:
    velero:
      logLevel: warning

The following 

logLevel
values are available: 

  • trace
     
  • debug
     
  • info
     
  • warning
     
  • error
     
  • fatal
     
  • panic

It is recommended to use 

debug
for most logs.

4.4.4. Debugging Velero resources with the Velero CLI tool
Copiar enlace

You can debug 

Backup
and 
Restore
custom resources (CRs) and retrieve logs with the Velero CLI tool.

The Velero CLI tool provides more detailed information than the OpenShift CLI tool.

Syntax

Use the 

oc exec
command to run a Velero CLI command: 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> <command> <cr_name>

Example

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

Help option

Use the 

velero --help
option to list all Velero CLI commands: 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  --help
Describe command

Use the 

velero describe
command to retrieve a summary of warnings and errors associated with a 
Backup
or 
Restore
CR: 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> describe <cr_name>

Example

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

Logs command

Use the 

velero logs
command to retrieve the logs of a 
Backup
or 
Restore
CR: 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> logs <cr_name>

Example

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

4.4.5. Installation issues
Copiar enlace

You might encounter issues caused by using invalid directories or incorrect credentials when you install the Data Protection Application.

4.4.5.1. Backup storage contains invalid directories
Copiar enlace

The 

Velero
pod log displays the error message, 
Backup storage contains invalid top-level directories
.

Cause

The object storage contains top-level directories that are not Velero directories.

Solution

If the object storage is not dedicated to Velero, you must specify a prefix for the bucket by setting the 

spec.backupLocations.velero.objectStorage.prefix
parameter in the 
DataProtectionApplication
manifest.

4.4.5.2. Incorrect AWS credentials
Copiar enlace

The 

oadp-aws-registry
pod log displays the error message, 
InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records.

The 

Velero
pod log displays the error message, 
NoCredentialProviders: no valid providers in chain
.

Cause

The 

credentials-velero
file used to create the 
Secret
object is incorrectly formatted.

Solution

Ensure that the 

credentials-velero
file is correctly formatted, as in the following example:

Example credentials-velero file

[default]
1 

aws_access_key_id=AKIAIOSFODNN7EXAMPLE
2 

aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

1
AWS default profile.
2
Do not enclose the values with quotation marks (", ').

4.4.6. Backup and Restore CR issues
Copiar enlace

You might encounter these common issues with 

Backup
and 
Restore
custom resources (CRs).

4.4.6.1. Backup CR cannot retrieve volume
Copiar enlace

The 

Backup
CR displays the error message, 
InvalidVolume.NotFound: The volume ‘vol-xxxx’ does not exist
.

Cause

The persistent volume (PV) and the snapshot locations are in different regions.

Solution

  1. Edit the value of the 
    spec.snapshotLocations.velero.config.region
    key in the 
    DataProtectionApplication
    manifest so that the snapshot location is in the same region as the PV.
  2. Create a new 
    Backup
    CR.

4.4.6.2. Backup CR status remains in progress
Copiar enlace

The status of a 

Backup
CR remains in the 
InProgress
phase and does not complete.

Cause

If a backup is interrupted, it cannot be resumed.

Solution

  1. Retrieve the details of the 

    Backup
    CR: 

    $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
  backup describe <backup>

  2. Delete the 

    Backup
    CR: 

    $ oc delete backup <backup> -n openshift-adp

    You do not need to clean up the backup location because a 

    Backup
    CR in progress has not uploaded files to object storage.

  3. Create a new 
    Backup
    CR.

4.4.7. Restic issues
Copiar enlace

You might encounter these issues when you back up applications with Restic.

The 

Restic
pod log displays the error message, 
controller=pod-volume-backup error="fork/exec/usr/bin/restic: permission denied"
.

Cause

If your NFS data volumes have 

root_squash
enabled, 
Restic
maps to 
nfsnobody
and does not have permission to create backups.

Solution

You can resolve this issue by creating a supplemental group for 

Restic
and adding the group ID to the 
DataProtectionApplication
manifest:

  1. Create a supplemental group for 
    Restic
    on the NFS data volume.
  2. Set the 
    setgid
    bit on the NFS directories so that group ownership is inherited.

  3. Add the 

    spec.configuration.restic.supplementalGroups
    parameter and the group ID to the 
    DataProtectionApplication
    manifest, as in the following example: 

    spec:
  configuration:
    restic:
      enable: true
      supplementalGroups:
      - <group_id>
    1
    1
    Specify the supplemental group ID.
  4. Wait for the 
    Restic
    pods to restart so that the changes are applied.

The 

Restore
CR of a Restic backup completes with a 
PartiallyFailed
or 
Failed
status or it remains 
InProgress
and does not complete.

If the status is 

PartiallyFailed
or 
Failed
, the 
Velero
pod log displays the error message, 
level=error msg="unable to successfully complete restic restores of pod’s volumes"
.

If the status is 

InProgress
, the 
Restore
CR logs are unavailable and no errors appear in the 
Restic
pod logs.

Cause

The 

DeploymentConfig
object redeploys the 
Restore
pod, causing the 
Restore
CR to fail.

Solution

  1. Create a 

    Restore
    CR that excludes the 
    ReplicationController
    , 
    DeploymentConfig
    , and 
    TemplateInstances
    resources: 

    $ velero restore create --from-backup=<backup> -n openshift-adp \
    1 
    
  --include-namespaces <namespace> \
    2 
    
  --exclude-resources replicationcontroller,deploymentconfig,templateinstances.template.openshift.io \
  --restore-volumes=true
    1
    Specify the name of the Backup CR.
    2
    Specify the include-namespaces in the Backup CR.

  2. Verify that the status of the 

    Restore
    CR is 
    Completed
    : 

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'

  3. Create a 

    Restore
    CR that includes the 
    ReplicationController
    and 
    DeploymentConfig
    resources: 

    $ velero restore create --from-backup=<backup> -n openshift-adp \
  --include-namespaces <namespace> \
  --include-resources replicationcontroller,deploymentconfig \
  --restore-volumes=true

  4. Verify that the status of the 

    Restore
    CR is 
    Completed
    : 

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'

  5. Verify that the backup resources have been restored: 

    $ oc get all -n <namespace>

4.4.7.3. Restic Backup CR cannot be recreated after bucket is emptied
Copiar enlace

If you create a Restic 

Backup
CR for a namespace, empty the S3 bucket, and then recreate the 
Backup
CR for the same namespace, the recreated 
Backup
CR fails.

The 

velero
pod log displays the error message, 
msg="Error checking repository for stale locks"
.

Cause

Velero does not create the Restic repository from the 

ResticRepository
manifest if the Restic directories are deleted on object storage. See (Velero issue 4421) for details.

4.4.8. Using the must-gather tool
Copiar enlace

You can collect logs, metrics, and information about OADP custom resources by using the 

must-gather
tool.

The 

must-gather
data must be attached to all customer cases.

You can run the 

must-gather
tool with the following data collection options:

  • Full 
    must-gather
    data collection collects Prometheus metrics, pod logs, and Velero CR information for all namespaces where the OADP Operator is installed.
  • Essential 
    must-gather
    data collection collects pod logs and Velero CR information for a specific duration of time, for example, one hour or 24 hours. Prometheus metrics and duplicate logs are not included. 
  • must-gather
    data collection with timeout. Data collection can take a long time if there are many failed 
    Backup
    CRs. You can improve performance by setting a timeout value.
  • Prometheus metrics data dump downloads an archive file containing the metrics data collected by Prometheus.

Prerequisites

  • You must be logged in to the OpenShift Container Platform cluster as a user with the 
    cluster-admin
    role.
  • You must have the OpenShift CLI (
    oc
    ) installed.

Procedure

  1. Navigate to the directory where you want to store the 
    must-gather
    data.

  2. Run the 

    oc adm must-gather
    command for one of the following data collection options:

    • Full 

      must-gather
      data collection, including Prometheus metrics: 

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.0

      The data is saved as 

      must-gather/must-gather.tar.gz
      . You can upload this file to a support case on the Red Hat Customer Portal.

    • Essential 

      must-gather
      data collection, without Prometheus metrics, for a specific time duration: 

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.0 \
  -- /usr/bin/gather_<time>_essential
      1
      1
      Specify the time in hours. Allowed values are 1h, 6h, 24h, 72h, or all, for example, gather_1h_essential or gather_all_essential. 

    • must-gather
      data collection with timeout: 

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.0 \
  -- /usr/bin/gather_with_timeout <timeout>
      1
      1
      Specify a timeout value in seconds.

    • Prometheus metrics data dump: 

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.0 \
  -- /usr/bin/gather_metrics_dump

      This operation can take a long time. The data is saved as 

      must-gather/metrics/prom_data.tar.gz
      .

Viewing metrics data with the Prometheus console

You can view the metrics data with the Prometheus console.

Procedure

  1. Decompress the 

    prom_data.tar.gz
    file: 

    $ tar -xvzf must-gather/metrics/prom_data.tar.gz

  2. Create a local Prometheus instance: 

    $ make prometheus-run

    The command outputs the Prometheus URL.

    Output

    Started Prometheus on http://localhost:9090

  3. Launch a web browser and navigate to the URL to view the data by using the Prometheus web console.

  4. After you have viewed the data, delete the Prometheus instance and data: 

    $ make prometheus-cleanup
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red HatVolver arriba