openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

Merge pull request #104943 from openshift-cherrypick-robot/cherry-pick-104376-to-enterprise-4.21

Browse Source 
[enterprise-4.21] OADP-7031 fix callouts and dita errors
This commit is contained in:
Shruti Deshpande
2026-01-19 17:31:40 +05:30
committed by GitHub
parent a3a9b2896a de4d687c07
commit 2fc0ca3fbc
12 changed files with 235 additions and 158 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
backup_and_restore/application_backup_and_restore/installing/about-oadp-data-mover.adoc
View File

@@ -7,78 +7,19 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
{oadp-first} includes a built-in Data Mover that you can use to move Container Storage Interface (CSI) volume snapshots to a remote object store. The built-in Data Mover allows you to restore stateful applications from the remote object store if a failure, accidental deletion, or corruption of the cluster occurs. It uses xref:../../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-about-kopia.adoc#oadp-about-kopia[Kopia] as the uploader mechanism to read the snapshot data and write to the unified repository.
Use the {oadp-first} built-in Data Mover to move Container Storage Interface (CSI) volume snapshots to remote object storage and restore stateful applications after cluster failures. This provides disaster recovery capabilities for both containerized and virtual machine workloads.
The Data Mover uses xref:../../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-about-kopia.adoc#oadp-about-kopia[Kopia] as the uploader mechanism to read the snapshot data and write to the unified repository.
{oadp-short} supports CSI snapshots on the following:
* {odf-full}
* Any other cloud storage provider with the Container Storage Interface (CSI) driver that supports the Kubernetes Volume Snapshot API
// ** suggest removing the admonition and replacing with a clear section **
//
// [IMPORTANT]
// ====
// The {oadp-short} built-in Data Mover, which was introduced in {oadp-short} 1.3 as a Technology Preview, is now fully supported for both containerized and virtual machine workloads.
// ====
include::modules/oadp-data-mover-support.adoc[leveloffset=+1]
[id="oadp-data-mover-support_{context}"]
== Data Mover support
include::modules/oadp-enabling-built-in-data-mover.adoc[leveloffset=+1]
The {oadp-short} built-in Data Mover, which was introduced in {oadp-short} 1.3 as a Technology Preview, is now fully supported for both containerized and virtual machine workloads.
.Supported
The Data Mover backups taken with {oadp-short} 1.3 can be restored using {oadp-short} 1.3, 1.4, and later. This is supported.
.Not supported
Backups taken with {oadp-short} 1.1 or {oadp-short} 1.2 using the Data Mover feature cannot be restored using {oadp-short} 1.3 and later. Therefore, it is not supported.
{oadp-short} 1.1 and {oadp-short} 1.2 are no longer supported. The DataMover feature in {oadp-short} 1.1 or {oadp-short} 1.2 was a Technology Preview and was never supported. DataMover backups taken with {oadp-short} 1.1 or {oadp-short} 1.2 cannot be restored on later versions of {oadp-short}.
[id="enabling-oadp-data-mover_{context}"]
== Enabling the built-in Data Mover
To enable the built-in Data Mover, you must include the CSI plugin and enable the node agent in the `DataProtectionApplication` custom resource (CR). The node agent is a Kubernetes daemonset that hosts data movement modules. These include the Data Mover controller, uploader, and the repository.
.Example `DataProtectionApplication` manifest
[source,yaml]
----
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: dpa-sample
spec:
configuration:
nodeAgent:
enable: true <1>
uploaderType: kopia <2>
velero:
defaultPlugins:
- openshift
- aws
- csi <3>
defaultSnapshotMoveData: true
defaultVolumesToFSBackup: <4>
featureFlags:
- EnableCSI
# ...
----
<1> The flag to enable the node agent.
<2> The type of uploader. The possible values are `restic` or `kopia`. The built-in Data Mover uses Kopia as the default uploader mechanism regardless of the value of the `uploaderType` field.
<3> The CSI plugin included in the list of default plugins.
<4> In {oadp-short} 1.3.1 and later, set to `true` if you use Data Mover only for volumes that opt out of `fs-backup`. Set to `false` if you use Data Mover by default for volumes.
[id="built-in-data-mover-crs"]
== Built-in Data Mover controller and custom resource definitions (CRDs)
The built-in Data Mover feature introduces three new API objects defined as CRDs for managing backup and restore:
* `DataDownload`: Represents a data download of a volume snapshot. The CSI plugin creates one `DataDownload` object per volume to be restored. The `DataDownload` CR includes information about the target volume, the specified Data Mover, the progress of the current data download, the specified backup repository, and the result of the current data download after the process is complete.
* `DataUpload`: Represents a data upload of a volume snapshot. The CSI plugin creates one `DataUpload` object per CSI snapshot. The `DataUpload` CR includes information about the specified snapshot, the specified Data Mover, the specified backup repository, the progress of the current data upload, and the result of the current data upload after the process is complete.
* `BackupRepository`: Represents and manages the lifecycle of the backup repositories. {oadp-short} creates a backup repository per namespace when the first CSI snapshot backup or restore for a namespace is requested.
include::modules/oadp-data-mover-crds.adoc[leveloffset=+1]
include::modules/oadp-incremental-backup-support.adoc[leveloffset=+1]

2
backup_and_restore/application_backup_and_restore/installing/configuring-backup-restore-pvc-datamover.adoc
View File

@@ -7,7 +7,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
A backup PVC is an intermediate persistent volume claim (PVC) to store data during the data movement backup operation. For some storage classes, such as, CephFS, creating a read-only volume from a snapshot results in faster Data Mover backups.
Configure backup and restore persistent volume claims (PVCs) to optimize Data Mover operations. For storage classes like CephFS, these intermediate PVCs allow the system to create read-only volumes from snapshots, resulting in significantly faster backups.
You create a `readonly` backup PVC by using the `nodeAgent.backupPVC` section of the `DataProtectionApplication` (DPA) and setting the `readOnly` access mode to `true`.

8
backup_and_restore/application_backup_and_restore/installing/configuring-oadp-multiple-bsl.adoc
View File

@@ -8,16 +8,14 @@ include::_attributes/common-attributes.adoc[]
toc::[]
You can configure one or more backup storage locations (BSLs) in the Data Protection Application (DPA). You can also select the location to store the backup in when you create the backup. With this configuration, you can store your backups in the following ways:
* To different regions
* To a different storage provider
[role="_abstract"]
Configure multiple backup storage locations (BSLs) in the Data Protection Application (DPA) to store backups across different regions or storage providers. This provides flexibility and redundancy for your backup strategy.
{oadp-short} supports multiple credentials for configuring more than one BSL, so that you can specify the credentials to use with any BSL.
// module for configuring the DPA with multiple BSLs.
include::modules/oadp-configuring-dpa-multiple-bsl.adoc[leveloffset=+1]
// module for multiple BSL use case.
include::modules/oadp-multiple-bsl-use-case.adoc[leveloffset=+1]

4
backup_and_restore/application_backup_and_restore/installing/configuring-oadp-multiple-vsl.adoc
View File

@@ -7,8 +7,8 @@ include::_attributes/common-attributes.adoc[]
toc::[]
You can configure one or more Volume Snapshot Locations (VSLs) to store the snapshots in different cloud provider regions.
[role="_abstract"]
Configure multiple Volume Snapshot Locations (VSLs) in the Data Protection Application (DPA) to store volume snapshots across different cloud provider regions. This provides geographic redundancy and regional disaster recovery capabilities.
// module for configuring the DPA with multiple VSLs.
include::modules/oadp-configuring-dpa-multiple-vsl.adoc[leveloffset=+1]

26
modules/oadp-configuring-backup-pvc-datamover-backup.adoc
View File

@@ -7,7 +7,7 @@
= Configuring a backup PVC for a Data Mover backup
[role="_abstract"]
Use the `nodeAgent.backupPVC` section of the `DataProtectionApplication` (DPA) object to configure the backup persistent volume claim (PVC) for a storage class.
Configure backup persistent volume claim (PVC) settings in the `DataProtectionApplication` (DPA) to optimize Data Mover backup performance for different storage classes. The feature gives you read-only access modes for faster data movement.
.Prerequisites
@@ -40,24 +40,27 @@ spec:
nodeAgent:
enable: true
uploaderType: kopia
backupPVC: # <1>
storage-class-1:
readOnly: true # <2>
spcNoRelabeling: true # <3>
backupPVC:
storage-class-1:
readOnly: true
spcNoRelabeling: true
storageClass: gp3-csi
storage-class-2:
readOnly: false
spcNoRelabeling: false
storageClass: gp3-csi
storageClass: gp3-csi
velero:
defaultPlugins:
- gcp
- openshift
- csi
----
<1> In this example, the `backupPVC` section has configurations for two storage classes, `storage-class-1` and `storage-class-2`.
<2> The `backupPVC` for `storage-class-1` is configured as `readOnly`.
<3> Because the `backupPVC` for `storage-class-1` is `readOnly`, the `spcNoRelabeling` field is set to `true`.
+
where:
+
`backupPVC`:: Specifies the `backupPVC` section. In this example, the `backupPVC` section has configurations for two storage classes, `storage-class-1` and `storage-class-2`.
`readOnly`:: Specifies that the `backupPVC` for `storage-class-1` is configured as `readOnly`.
`spcNoRelabeling`:: Specifies that the `spcNoRelabeling` field is set to `true` because the `backupPVC` for `storage-class-1` is `readOnly`.
. Create a `Backup` custom resource by using the following configuration:
+
@@ -72,9 +75,10 @@ metadata:
spec:
includedNamespaces:
- <application_namespace>
snapshotMoveData: true # <1>
snapshotMoveData: true
----
<1> Set to `true` for a Data Mover backup.
+
`snapshotMoveData`:: Set to `true` for a Data Mover backup.
.Verification

62
modules/oadp-configuring-dpa-multiple-bsl.adoc
View File

@@ -8,9 +8,9 @@
= Configuring the DPA with more than one BSL
[role="_abstract"]
You can configure the `DataProtectionApplication` (DPA) custom resource (CR) with more than one `BackupStorageLocation` (BSL) CR and specify the credentials provided by the cloud provider.
Configure the `DataProtectionApplication` (DPA) custom resource (CR) with multiple `BackupStorageLocation` (BSL) resources to store backups across different locations using provider-specific credentials. This provides backup distribution and location-specific restore capabilities.
For example, where you have configured the following two BSLs:
For example, you have configured the following two BSLs:
* Configured one BSL in the DPA and set it as the default BSL.
* Created another BSL independently by using the `BackupStorageLocation` CR.
@@ -33,46 +33,49 @@ apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
#...
backupLocations:
- name: aws # <1>
- name: aws
velero:
provider: aws
default: true # <2>
default: true
objectStorage:
bucket: <bucket_name> # <3>
prefix: <prefix> # <4>
bucket: <bucket_name>
prefix: <prefix>
config:
region: <region_name> # <5>
region: <region_name>
profile: "default"
credential:
key: cloud
name: cloud-credentials # <6>
- name: odf # <7>
name: cloud-credentials
- name: odf
velero:
provider: aws
default: false
objectStorage:
bucket: <bucket_name>
prefix: <prefix>
bucket: <bucket_name>
prefix: <prefix>
config:
profile: "default"
profile: "default"
region: <region_name>
s3Url: <url> # <8>
s3Url: <url>
insecureSkipTLSVerify: "true"
s3ForcePathStyle: "true"
credential:
key: cloud
name: <custom_secret_name_odf> # <9>
name: <custom_secret_name_odf>
#...
----
<1> Specify a name for the first BSL.
<2> This parameter indicates that this BSL is the default BSL. If a BSL is not set in the `Backup CR`, the default BSL is used. You can set only one BSL as the default.
<3> Specify the bucket name.
<4> Specify a prefix for Velero backups; for example, `velero`.
<5> Specify the AWS region for the bucket.
<6> Specify the name of the default `Secret` object that you created.
<7> Specify a name for the second BSL.
<8> Specify the URL of the S3 endpoint.
<9> Specify the correct name for the `Secret`; for example, `custom_secret_name_odf`. If you do not specify a `Secret` name, the default name is used.
+
where:
+
`name: aws`:: Specifies a name for the first BSL.
`default: true`:: Indicates that this BSL is the default BSL. If a BSL is not set in the `Backup CR`, the default BSL is used. You can set only one BSL as the default.
`<bucket_name>`:: Specifies the bucket name.
`<prefix>`:: Specifies a prefix for Velero backups. For example, `velero`.
`<region_name>`:: Specifies the AWS region for the bucket.
`cloud-credentials`:: Specifies the name of the default `Secret` object that you created.
`name: odf`:: Specifies a name for the second BSL.
`<url>`:: Specifies the URL of the S3 endpoint.
`<custom_secret_name_odf>`:: Specifies the correct name for the `Secret`. For example, `custom_secret_name_odf`. If you do not specify a `Secret` name, the default name is used.
. Specify the BSL to be used in the backup CR. See the following example.
+
@@ -84,9 +87,12 @@ kind: Backup
# ...
spec:
includedNamespaces:
- <namespace> # <1>
storageLocation: <backup_storage_location> # <2>
defaultVolumesToFsBackup: true
- <namespace>
storageLocation: <backup_storage_location>
defaultVolumesToFsBackup: true
----
<1> Specify the namespace to back up.
<2> Specify the storage location.
+
where:
+
`<namespace>`:: Specifies the namespace to back up.
`<backup_storage_location>`:: Specifies the storage location.

22
modules/oadp-configuring-dpa-multiple-vsl.adoc
View File

@@ -3,13 +3,18 @@
// * backup_and_restore/application_backup_and_restore/installing/configuring-oadp-multiple-vsl.adoc
:_mod-docs-content-type: CONCEPT
:_mod-docs-content-type: PROCEDURE
[id="oadp-configuring-dpa-multiple-vsl_{context}"]
= Configuring the DPA with more than one VSL
You configure the DPA with more than one VSL and specify the credentials provided by the cloud provider. Make sure that you configure the snapshot location in the same region as the persistent volumes. See the following example.
[role="_abstract"]
Configure the `DataProtectionApplication` (DPA) custom resource (CR) with multiple Volume Snapshot Locations (VSLs) using provider-specific credentials in the same region as your persistent volumes. This provides volume snapshot distribution across different storage targets.
.Example DPA
.Procedure
* Configure the DPA CR with more than one VSL as shown in the following example:
+
[source,yaml]
----
apiVersion: oadp.openshift.io/v1alpha1
@@ -19,7 +24,7 @@ snapshotLocations:
- velero:
config:
profile: default
region: <region> # <1>
region: <region>
credential:
key: cloud
name: cloud-credentials
@@ -30,9 +35,12 @@ snapshotLocations:
region: <region>
credential:
key: cloud
name: <custom_credential> # <2>
name: <custom_credential>
provider: aws
#...
----
<1> Specify the region. The snapshot location must be in the same region as the persistent volumes.
<2> Specify the custom credential name.
+
where:
`<region>`:: Specifies the region. The snapshot location must be in the same region as the persistent volumes.
`<custom_credential>`:: Specifies the custom credential name.

13
modules/oadp-configuring-restore-pvc-datamover-restore.adoc
View File

@@ -7,6 +7,8 @@
= Configuring a restorePVC for a Data Mover restore
[role="_abstract"]
Configure restore persistent volume claim (PVC) settings in the `DataProtectionApplication` (DPA) to optimize Data Mover restore operations and enable parallel volume restores. This improves restore performance by distributing restore pods across nodes.
A `restorePVC` is an intermediate PVC that is used to write data during the Data Mover restore operation.
You can configure the `restorePVC` in the `DataProtectionApplication` (DPA) object by using the `ignoreDelayBinding` field. Setting the `ignoreDelayBinding` field to `true` allows the restore operation to ignore the `WaitForFirstConsumer` binding mode. The data movement restore operation then creates the restore pod and provisions the associated volume to an arbitrary node.
@@ -36,8 +38,11 @@ spec:
nodeAgent:
enable: true
uploaderType: kopia
restorePVC: # <1>
ignoreDelayBinding: true # <2>
restorePVC:
ignoreDelayBinding: true
----
<1> Add the `restorePVC` section.
<2> Set the `ignoreDelayBinding` field to `true`.
+
where:
+
`restorePVC`:: Specifies the `restorePVC` section.
`ignoreDelayBinding`:: Set the `ignoreDelayBinding` field to `true`.

18
modules/oadp-data-mover-crds.adoc Normal file
View File

@@ -0,0 +1,18 @@
// Module included in the following assemblies:
//
// backup_and_restore/application_backup_and_restore/installing/about-oadp-data-mover.adoc
:_mod-docs-content-type: CONCEPT
[id="built-in-data-mover-crds_{context}"]
= Built-in Data Mover controller and custom resource definitions (CRDs)
[role="_abstract"]
Review the custom resource definitions (CRDs) that the built-in Data Mover uses to manage volume snapshot backup and restore operations. This helps you understand how Data Mover handles data upload, download, and repository management.
The built-in Data Mover feature introduces three new API objects defined as CRDs for managing backup and restore:
* `DataDownload`: Represents a data download of a volume snapshot. The CSI plugin creates one `DataDownload` object per volume to be restored. The `DataDownload` CR includes information about the target volume, the specified Data Mover, the progress of the current data download, the specified backup repository, and the result of the current data download after the process is complete.
* `DataUpload`: Represents a data upload of a volume snapshot. The CSI plugin creates one `DataUpload` object per CSI snapshot. The `DataUpload` CR includes information about the specified snapshot, the specified Data Mover, the specified backup repository, the progress of the current data upload, and the result of the current data upload after the process is complete.
* `BackupRepository`: Represents and manages the lifecycle of the backup repositories. {oadp-short} creates a backup repository per namespace when the first CSI snapshot backup or restore for a namespace is requested.

22
modules/oadp-data-mover-support.adoc Normal file
View File

@@ -0,0 +1,22 @@
// Module included in the following assemblies:
//
// backup_and_restore/application_backup_and_restore/installing/about-oadp-data-mover.adoc
:_mod-docs-content-type: CONCEPT
[id="oadp-data-mover-support_{context}"]
= Data Mover support
[role="_abstract"]
Review Data Mover support and compatibility across {oadp-short} versions to understand which backups can be restored. This helps you plan version upgrades and backup strategies.
The {oadp-short} built-in Data Mover, which was introduced in {oadp-short} 1.3 as a Technology Preview, is now fully supported for both containerized and virtual machine workloads.
Supported::
The Data Mover backups taken with {oadp-short} 1.3 can be restored using {oadp-short} 1.3 and later.
Not supported::
Backups taken with {oadp-short} 1.1 or {oadp-short} 1.2 using the Data Mover feature cannot be restored using {oadp-short} 1.3 and later.
{oadp-short} 1.1 and {oadp-short} 1.2 are no longer supported. The DataMover feature in {oadp-short} 1.1 or {oadp-short} 1.2 was a Technology Preview and was never supported. DataMover backups taken with {oadp-short} 1.1 or {oadp-short} 1.2 cannot be restored on later versions of {oadp-short}.

44
modules/oadp-enabling-built-in-data-mover.adoc Normal file
View File

@@ -0,0 +1,44 @@
// Module included in the following assemblies:
//
// backup_and_restore/application_backup_and_restore/installing/about-oadp-data-mover.adoc
:_mod-docs-content-type: PROCEDURE
[id="enabling-oadp-data-mover_{context}"]
= Enabling the built-in Data Mover
[role="_abstract"]
Enable the built-in Data Mover by configuring the CSI plugin and node agent in the `DataProtectionApplication` custom resource (CR). This provides volume-level backup and restore operations by using the Kopia uploader.
.Procedure
* Include the CSI plugin and enable the node agent in the `DataProtectionApplication` custom resource (CR) as shown in the following example:
+
[source,yaml]
----
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: dpa-sample
spec:
configuration:
nodeAgent:
enable: true
uploaderType: kopia
velero:
defaultPlugins:
- openshift
- aws
- csi
defaultSnapshotMoveData: true
defaultVolumesToFSBackup:
featureFlags:
- EnableCSI
# ...
----
+
where:
`enable`:: Specifies the flag to enable the node agent.
`uploaderType`:: Specifies the type of uploader. The possible values are `restic` or `kopia`. The built-in Data Mover uses Kopia as the default uploader mechanism regardless of the value of the `uploaderType` field.
`csi`:: Specifies the CSI plugin included in the list of default plugins.
`defaultVolumesToFSBackup`:: Specifies the default behavior for volumes. In {oadp-short} 1.3.1 and later, set to `true` if you use Data Mover only for volumes that opt out of `fs-backup`. Set to `false` if you use Data Mover by default for volumes.

101
modules/oadp-multiple-bsl-use-case.adoc
View File

@@ -5,9 +5,11 @@
:_mod-docs-content-type: PROCEDURE
[id="oadp-multiple-bsl-use-case_{context}"]
= {oadp-short} use case for two BSLs
= Configuring two backup BSLs with different cloud credentials
[role="_abstract"]
Configure two backup storage locations with different cloud credentials to back up applications to multiple storage targets. With this setup, you can distribute backups across different storage providers for redundancy.
In this use case, you configure the DPA with two storage locations by using two cloud credentials. You back up an application with a database by using the default BSL. {oadp-short} stores the backup resources in the default BSL. You then backup the application again by using the second BSL.
.Prerequisites
@@ -21,17 +23,23 @@ In this use case, you configure the DPA with two storage locations by using two
+
[source,terminal]
----
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=<aws_credentials_file_name> # <1>
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=<aws_credentials_file_name>
----
<1> Specify the name of the cloud credentials file for AWS S3.
+
where:
+
`<aws_credentials_file_name>`:: Specifies the name of the cloud credentials file for AWS S3.
. Create the second `Secret` for MCG with a custom name by running the following command:
+
[source,terminal]
----
$ oc create secret generic mcg-secret -n openshift-adp --from-file cloud=<MCG_credentials_file_name> # <1>
$ oc create secret generic mcg-secret -n openshift-adp --from-file cloud=<MCG_credentials_file_name>
----
<1> Specify the name of the cloud credentials file for MCG. Note the name of the `mcg-secret` custom secret.
+
where:
+
`<MCG_credentials_file_name>`:: Specifies the name of the cloud credentials file for MCG. Note the name of the `mcg-secret` custom secret.
. Configure the DPA with the two BSLs as shown in the following example.
+
@@ -49,13 +57,13 @@ spec:
velero:
config:
profile: default
region: <region_name> # <1>
region: <region_name>
credential:
key: cloud
name: cloud-credentials
default: true
objectStorage:
bucket: <bucket_name> # <2>
bucket: <bucket_name>
prefix: velero
provider: aws
- name: mcg
@@ -63,14 +71,14 @@ spec:
config:
insecureSkipTLSVerify: "true"
profile: noobaa
region: <region_name> # <3>
region: <region_name>
s3ForcePathStyle: "true"
s3Url: <s3_url> # <4>
s3Url: <s3_url>
credential:
key: cloud
name: mcg-secret # <5>
name: mcg-secret
objectStorage:
bucket: <bucket_name_mcg> # <6>
bucket: <bucket_name_mcg>
prefix: velero
provider: aws
configuration:
@@ -82,20 +90,26 @@ spec:
- openshift
- aws
----
<1> Specify the AWS region for the bucket.
<2> Specify the AWS S3 bucket name.
<3> Specify the region, following the naming convention of the documentation of MCG.
<4> Specify the URL of the S3 endpoint for MCG.
<5> Specify the name of the custom secret for MCG storage.
<6> Specify the MCG bucket name.
+
where:
+
`<region_name>`:: Specifies the AWS region for the bucket.
`<bucket_name>`:: Specifies the AWS S3 bucket name.
`region: <region_name>`:: Specifies the region, following the naming convention of the documentation of MCG.
`<s3_url>`:: Specifies the URL of the S3 endpoint for MCG.
`mcg-secret`:: Specifies the name of the custom secret for MCG storage.
`<bucket_name_mcg>`:: Specifies the MCG bucket name.
. Create the DPA by running the following command:
+
[source,terminal]
----
$ oc create -f <dpa_file_name> # <1>
$ oc create -f <dpa_file_name>
----
<1> Specify the file name of the DPA you configured.
+
where:
+
`<dpa_file_name>`:: Specifies the file name of the DPA you configured.
. Verify that the DPA has reconciled by running the following command:
+
@@ -136,26 +150,35 @@ metadata:
namespace: openshift-adp
spec:
includedNamespaces:
- <mysql_namespace> # <1>
- <mysql_namespace>
defaultVolumesToFsBackup: true
----
<1> Specify the namespace for the application installed in the cluster.
+
where:
+
`<mysql_namespace>`:: Specifies the namespace for the application installed in the cluster.
. Create a backup by running the following command:
+
[source,terminal]
----
$ oc apply -f <backup_file_name> # <1>
$ oc apply -f <backup_file_name>
----
<1> Specify the name of the backup CR file.
+
where:
+
`<backup_file_name>`:: Specifies the name of the backup CR file.
. Verify that the backup completed with the default BSL by running the following command:
+
[source,terminal]
----
$ oc get backups.velero.io <backup_name> -o yaml # <1>
$ oc get backups.velero.io <backup_name> -o yaml
----
<1> Specify the name of the backup.
+
where:
+
`<backup_name>`:: Specifies the name of the backup.
. Create a backup CR by using MCG as the BSL. In the following example, note that the second `storageLocation` value is specified at the time of backup CR creation.
+
@@ -169,26 +192,34 @@ metadata:
namespace: openshift-adp
spec:
includedNamespaces:
- <mysql_namespace> # <1>
storageLocation: mcg # <2>
- <mysql_namespace>
storageLocation: mcg
defaultVolumesToFsBackup: true
----
<1> Specify the namespace for the application installed in the cluster.
<2> Specify the second storage location.
+
where:
+
`<mysql_namespace>`:: Specifies the namespace for the application installed in the cluster.
`mcg`:: Specifies the second storage location.
. Create a second backup by running the following command:
+
[source, terminal]
----
$ oc apply -f <backup_file_name> # <1>
$ oc apply -f <backup_file_name>
----
<1> Specify the name of the backup CR file.
+
where:
+
`<backup_file_name>`:: Specifies the name of the backup CR file.
. Verify that the backup completed with the storage location as MCG by running the following command:
+
[source, terminal]
----
$ oc get backups.velero.io <backup_name> -o yaml # <1>
$ oc get backups.velero.io <backup_name> -o yaml
----
<1> Specify the name of the backup.
+
where:
+
`<backup_name>`:: Specifies the name of the backup.