mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
Merge pull request #98492 from openshift-cherrypick-robot/cherry-pick-98223-to-enterprise-4.20
[enterprise-4.20] DITA fixes for OADP troubleshooting
This commit is contained in:
Shruti Deshpande
@@ -42,6 +42,8 @@ endif::[]
|
||||
:hybrid-console-second: Hybrid Cloud Console
|
||||
:hybrid-console-url: link:https://console.redhat.com[Red Hat Hybrid Cloud Console]
|
||||
// OADP attributes
|
||||
:velero-domain: velero.io
|
||||
:velero-version: 1.16
|
||||
:oadp-first: OpenShift API for Data Protection (OADP)
|
||||
:oadp-full: OpenShift API for Data Protection
|
||||
:oadp-short: OADP
|
||||
@@ -50,7 +52,14 @@ endif::[]
|
||||
:oadp-version-1-4: 1.4.5
|
||||
:oadp-version-1-5: 1.5.0
|
||||
:oadp-bsl-api: backupstoragelocations.velero.io
|
||||
:velero-overview: link:https://{velero-domain}/docs/v{velero-version}/locations/[Overview of backup and snapshot locations in the Velero documentation]
|
||||
:velero-link: link:https://{velero-domain}/docs/v{velero-version}/[Velero {velero-version}]
|
||||
:velero-cli-install: link:https://{velero-domain}/docs/v{velero-version}/basic-install/#install-the-cli["Install the CLI" on the Velero website]
|
||||
:velero-1.12: link:https://{velero-domain}/docs/v1.12/[1.12]
|
||||
:velero-1.14: link:https://{velero-domain}/docs/v1.14/[1.14]
|
||||
:velero-1.16: link:https://{velero-domain}/docs/v1.16/[1.16]
|
||||
:ocp-user-workload-monitoring: link:https://docs.redhat.com/en/documentation/openshift_container_platform/{product-version}/html/monitoring/configuring-user-workload-monitoring[Configuring user workload monitoring]
|
||||
|
||||
:oc-first: pass:quotes[OpenShift CLI (`oc`)]
|
||||
:product-registry: OpenShift image registry
|
||||
:product-mirror-registry: Mirror registry for Red Hat OpenShift
|
||||
@@ -70,8 +79,6 @@ endif::[]
|
||||
:descheduler-operator: Kube Descheduler Operator
|
||||
:cli-manager: CLI Manager Operator
|
||||
// Backup and restore
|
||||
:velero-domain: velero.io
|
||||
:velero-version: 1.16
|
||||
:launch: image:app-launcher.png[title="Application Launcher"]
|
||||
:mtc-first: Migration Toolkit for Containers (MTC)
|
||||
:mtc-short: MTC
|
||||
|
||||
@@ -1,13 +1,16 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="about-installing-oadp"]
|
||||
= About installing OADP
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: about-installing-oadp
|
||||
|
||||
toc::[]
|
||||
|
||||
As a cluster administrator, you install the OpenShift API for Data Protection (OADP) by installing the OADP Operator. The OADP Operator installs link:https://{velero-domain}/docs/v{velero-version}/[Velero {velero-version}].
|
||||
|
||||
[role="_abstract"]
|
||||
As a cluster administrator, you install the OpenShift API for Data Protection (OADP) by installing the OADP Operator. The OADP Operator installs {velero-link}.
|
||||
|
||||
include::snippets/oadp-mtc-operator.adoc[]
|
||||
|
||||
@@ -56,7 +59,7 @@ include::modules/oadp-configuring-noobaa-for-dr.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* link:https://{velero-domain}/docs/v{velero-version}/locations/[Overview of backup and snapshot locations in the Velero documentation]
|
||||
* {velero-overview}
|
||||
|
||||
include::modules/about-oadp-update-channels.adoc[leveloffset=+1]
|
||||
include::modules/about-installing-oadp-on-multiple-namespaces.adoc[leveloffset=+1]
|
||||
|
||||
@@ -1,14 +1,17 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="backup-and-restore-cr-issues"]
|
||||
= Backup and Restore CR issues
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: backup-and-restore-cr-issues
|
||||
:namespace: openshift-adp
|
||||
:local-product: OADP
|
||||
|
||||
toc::[]
|
||||
|
||||
|
||||
[role="_abstract"]
|
||||
You might encounter the following common issues with `Backup` and `Restore` custom resources (CRs):
|
||||
|
||||
* Backup CR cannot retrieve volume
|
||||
|
||||
@@ -1,14 +1,17 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="oadp-installation-issues"]
|
||||
= OADP installation issues
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: installation-issues
|
||||
:namespace: openshift-adp
|
||||
:local-product: OADP
|
||||
|
||||
toc::[]
|
||||
|
||||
|
||||
[role="_abstract"]
|
||||
You might encounter issues caused by using invalid directories or incorrect credentials when you install the Data Protection Application (DPA).
|
||||
|
||||
include::modules/resolving-backup-storage-contains-invalid-directories-issue.adoc[leveloffset=+1]
|
||||
|
||||
@@ -1,14 +1,17 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="oadp-monitoring"]
|
||||
= OADP monitoring
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: oadp-monitoring
|
||||
:namespace: openshift-adp
|
||||
:local-product: OADP
|
||||
|
||||
toc::[]
|
||||
|
||||
|
||||
[role="_abstract"]
|
||||
By using the {product-title} monitoring stack, users and administrators can effectively perform the following tasks:
|
||||
|
||||
* Monitor and manage clusters
|
||||
|
||||
@@ -1,14 +1,17 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="oadp-operator-issues"]
|
||||
= OADP Operator issues
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: oadp-operator-issues
|
||||
:namespace: openshift-adp
|
||||
:local-product: OADP
|
||||
|
||||
toc::[]
|
||||
|
||||
|
||||
[role="_abstract"]
|
||||
The {oadp-first} Operator might encounter issues caused by problems it is not able to resolve.
|
||||
|
||||
include::modules/resolving-oadp-operator-fails-silently-issue.adoc[leveloffset=+1]
|
||||
@@ -1,14 +1,17 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="oadp-timeouts"]
|
||||
= OADP timeouts
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: oadp-timeouts
|
||||
:namespace: openshift-adp
|
||||
:local-product: OADP
|
||||
|
||||
toc::[]
|
||||
|
||||
|
||||
[role="_abstract"]
|
||||
Extending a timeout allows complex or resource-intensive processes to complete successfully without premature termination. This configuration can reduce errors, retries, or failures.
|
||||
|
||||
Ensure that you balance timeout extensions in a logical manner so that you do not configure excessively long timeouts that might hide underlying issues in the process. Consider and monitor an appropriate timeout value that meets the needs of the process and the overall system performance.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="pods-crash-or-restart-due-to-lack-of-memory-or-cpu"]
|
||||
= Pods crash or restart due to lack of memory or CPU
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: pods-crash-or-restart-due-to-lack-of-memory-or-cpu
|
||||
@@ -9,8 +11,9 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:must-gather-v1-3: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
|
||||
:must-gather-v1-4: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4
|
||||
|
||||
toc::[]
|
||||
|
||||
|
||||
[role="_abstract"]
|
||||
If a Velero or Restic pod crashes due to a lack of memory or CPU, you can set specific resource requests for either of those resources. The values for the resource request fields must follow the same format as Kubernetes resource requirements.
|
||||
|
||||
If you do not specify `configuration.velero.podConfig.resourceAllocations` or `configuration.restic.podConfig.resourceAllocations`, see the following default `resources` specification configuration for a Velero or Restic pod:
|
||||
|
||||
@@ -1,14 +1,17 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="restic-issues"]
|
||||
= Restic issues
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: restic-issues
|
||||
:namespace: openshift-adp
|
||||
:local-product: OADP
|
||||
|
||||
toc::[]
|
||||
|
||||
|
||||
[role="_abstract"]
|
||||
You might encounter the following issues when you back up applications with Restic:
|
||||
|
||||
* Restic permission error for NFS data volumes with the `root_squash` resource/parameter enabled
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="restoring-workarounds-for-velero-backups-that-use-admission-webhooks"]
|
||||
= Restoring workarounds for Velero backups that use admission webhooks
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: restoring-workarounds-for-velero-backups-that-use-admission-webhooks
|
||||
@@ -9,6 +11,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
[role="_abstract"]
|
||||
Velero has limited abilities to resolve admission webhook issues during a restore. If you have workloads with admission webhooks, you might need to use an additional Velero plugin or make changes to how you restore the workload.
|
||||
|
||||
Typically, workloads with admission webhooks require you to create a resource of a specific kind first. This is especially true if your workload has child resources because admission webhooks typically block child resources.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="troubleshooting"]
|
||||
= Troubleshooting
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: oadp-troubleshooting
|
||||
@@ -10,8 +12,8 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:must-gather-v1-3: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
|
||||
:must-gather-v1-4: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4
|
||||
|
||||
toc::[]
|
||||
|
||||
[role="_abstract"]
|
||||
You can troubleshoot OADP issues by using the following methods:
|
||||
|
||||
* Debug Velero custom resources (CRs) by using the xref:../../../backup_and_restore/application_backup_and_restore/troubleshooting/velero-cli-tool.adoc#oadp-debugging-oc-cli_velero-cli-tool[OpenShift CLI tool] or the xref:../../../backup_and_restore/application_backup_and_restore/troubleshooting/velero-cli-tool.adoc#migration-debugging-velero-resources_velero-cli-tool[Velero CLI tool]. The Velero CLI tool provides more detailed logs and information.
|
||||
|
||||
@@ -1,12 +1,14 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="using-the-must-gather-tool"]
|
||||
= Using the must-gather tool
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: using-the-must-gather-tool
|
||||
:must-gather-v1-5: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.5
|
||||
|
||||
toc::[]
|
||||
|
||||
[role="_abstract"]
|
||||
You can collect logs and information about {oadp-short} custom resources by using the `must-gather` tool. The `must-gather` data must be attached to all customer cases.
|
||||
|
||||
The `must-gather` tool is a container and does not run all the time. The tool runs for a few minutes only after you invoke the tool by running the `must-gather` command.
|
||||
|
||||
@@ -1,14 +1,17 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="velero-cli-tool"]
|
||||
= Velero CLI tool
|
||||
:toc:
|
||||
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: velero-cli-tool
|
||||
:namespace: openshift-adp
|
||||
:local-product: OADP
|
||||
|
||||
toc::[]
|
||||
|
||||
|
||||
[role="_abstract"]
|
||||
You can obtain the `velero` CLI tool by using the following options:
|
||||
|
||||
* Downloading the `velero` CLI tool
|
||||
|
||||
@@ -8,11 +8,12 @@
|
||||
[id="avoiding-the-velero-plugin-panic-error_{context}"]
|
||||
= Avoiding the Velero plugin panic error
|
||||
|
||||
[role="_abstract"]
|
||||
A missing secret can cause a panic error for the Velero plugin during image stream backups.
|
||||
|
||||
When the backup and the Backup Storage Location (BSL) are managed outside the scope of the Data Protection Application (DPA), the OADP controller does not create the relevant `oadp-<bsl_name>-<bsl_provider>-registry-secret` parameter.
|
||||
|
||||
During the backup operation, the OpenShift Velero plugin panics on the imagestream backup, with the following panic error:
|
||||
During the backup operation, the OpenShift Velero plugin panics on the `imagestream` backup, with the following panic error:
|
||||
|
||||
[source,text]
|
||||
----
|
||||
|
||||
@@ -5,6 +5,7 @@
|
||||
[id="migration-debugging-velero-admission-webhooks-ibm-appconnect_{context}"]
|
||||
= Restoring {ibm-title} AppConnect resources
|
||||
|
||||
[role="_abstract"]
|
||||
If you experience issues when you use Velero to a restore an {ibm-name} AppConnect resource that has an admission webhook, you can run the checks in this procedure.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -6,7 +6,8 @@
|
||||
[id="migration-debugging-velero-admission-webhooks-knative_{context}"]
|
||||
= Restoring Knative resources
|
||||
|
||||
You might encounter problems using Velero to back up Knative resources that use admission webhooks.
|
||||
[role="_abstract"]
|
||||
You might encounter problems by using Velero to back up Knative resources that use admission webhooks.
|
||||
|
||||
You can avoid such problems by restoring the top level `Service` resource whenever you back up and restore Knative resources that use admission webhooks.
|
||||
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="migration-debugging-velero-resources_{context}"]
|
||||
= Debugging Velero resources with the Velero CLI tool
|
||||
|
||||
[role="_abstract"]
|
||||
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.
|
||||
|
||||
.Procedure
|
||||
@@ -66,18 +67,17 @@ $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
|
||||
+
|
||||
The following types of restore errors and warnings are shown in the output of a `velero describe` request:
|
||||
+
|
||||
.`Velero`
|
||||
A list of messages related to the operation of Velero itself, for example, messages related to connecting to the cloud, reading a backup file, and so on
|
||||
* `Velero`: A list of messages related to the operation of Velero itself, for example, messages related to connecting to the cloud, reading a backup file, and so on
|
||||
+
|
||||
.`Cluster`
|
||||
A list of messages related to backing up or restoring cluster-scoped resources
|
||||
* `Cluster`: A list of messages related to backing up or restoring cluster-scoped resources
|
||||
+
|
||||
.`Namespaces`
|
||||
A list of list of messages related to backing up or restoring resources stored in namespaces
|
||||
* `Namespaces`: A list of list of messages related to backing up or restoring resources stored in namespaces
|
||||
|
||||
+
|
||||
One or more errors in one of these categories results in a `Restore` operation receiving the status of `PartiallyFailed` and not `Completed`. Warnings do not lead to a change in the completion status.
|
||||
|
||||
+
|
||||
|
||||
Consider the following points for these restore errors:
|
||||
|
||||
* For resource-specific errors, that is, `Cluster` and `Namespaces` errors, the `restore describe --details` output includes a resource list that includes all resources that Velero restored. For any resource that has such an error, check if the resource is actually in the cluster.
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="creating-alerting-rules_{context}"]
|
||||
= Creating an alerting rule
|
||||
|
||||
[role="_abstract"]
|
||||
The {product-title} monitoring stack receives Alerts configured by using Alerting Rules. To create an Alerting rule for the {oadp-short} project, use one of the Metrics scraped with the user workload monitoring.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="oadp-creating-service-monitor_{context}"]
|
||||
= Creating OADP service monitor
|
||||
|
||||
[role="_abstract"]
|
||||
{oadp-short} provides an `openshift-adp-velero-metrics-svc` service, which is created when the Data Protection Application (DPA) is configured. The user workload monitoring service monitor must point to the defined service.
|
||||
To get details about the service, complete the following steps.
|
||||
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="csisnapshot-timeout_{context}"]
|
||||
= Implementing CSI snapshot timeout
|
||||
|
||||
[role="_abstract"]
|
||||
`CSISnapshotTimeout` specifies the time during creation to wait until the `CSI VolumeSnapshot` status becomes `ReadyToUse`, before returning error as timeout. The default value is `10m`.
|
||||
|
||||
Use the `CSISnapshotTimeout` for the following scenarios:
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="datamover-timeout_{context}"]
|
||||
= Implementing Data Mover timeout
|
||||
|
||||
[role="_abstract"]
|
||||
`timeout` is a user-supplied timeout to complete `VolumeSnapshotBackup` and `VolumeSnapshotRestore`. The default value is `10m`.
|
||||
|
||||
Use the Data Mover `timeout` for the following scenarios:
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="oadp-debugging-oc-cli_{context}"]
|
||||
= Debugging Velero resources with the OpenShift CLI tool
|
||||
|
||||
[role="_abstract"]
|
||||
You can debug a failed backup or restore by checking Velero custom resources (CRs) and the `Velero` pod log with the OpenShift CLI tool.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="item-operation-timeout-backup_{context}"]
|
||||
= Implementing item operation timeout - backup
|
||||
|
||||
[role="_abstract"]
|
||||
The `ItemOperationTimeout` setting specifies the time used to wait for asynchronous
|
||||
`BackupItemAction` operations. The default value is `1h`.
|
||||
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="item-operation-timeout-restore_{context}"]
|
||||
= Implementing item operation timeout - restore
|
||||
|
||||
[role="_abstract"]
|
||||
The `ItemOperationTimeout` setting specifies the time that is used to wait for `RestoreItemAction` operations. The default value is `1h`.
|
||||
|
||||
Use the restore `ItemOperationTimeout` for the following scenarios:
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="list-of-metrics_{context}"]
|
||||
= List of available metrics
|
||||
|
||||
[role="_abstract"]
|
||||
Refer to the following table for a list of `Velero` metrics provided by {oadp-short} together with their https://prometheus.io/docs/concepts/metric_types/[Types]:
|
||||
|
||||
.Velero metrics
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="oadp-monitoring-setup-monitor_{context}"]
|
||||
= OADP monitoring setup
|
||||
|
||||
[role="_abstract"]
|
||||
The OADP Operator leverages an OpenShift User Workload Monitoring provided by the OpenShift Monitoring Stack for retrieving metrics from the Velero service endpoint. The monitoring stack allows creating user-defined Alerting Rules or querying metrics by using the OpenShift Metrics query front end.
|
||||
|
||||
With enabled User Workload Monitoring, it is possible to configure and use any Prometheus-compatible third-party UI, such as Grafana, to visualize Velero metrics.
|
||||
@@ -17,7 +18,7 @@ Monitoring metrics requires enabling monitoring for the user-defined projects an
|
||||
The {oadp-short} support for Prometheus metrics is offered on a best-effort basis and is not fully supported.
|
||||
====
|
||||
|
||||
For more information about setting up the monitoring stack, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/{product-version}/html/monitoring/configuring-user-workload-monitoring[Configuring user workload monitoring].
|
||||
For more information about setting up the monitoring stack, see {ocp-user-workload-monitoring}.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="oadp-pod-crash-resource-request-retics_{context}"]
|
||||
= Setting resource requests for a Restic pod
|
||||
|
||||
[role="_abstract"]
|
||||
You can use the `configuration.restic.podConfig.resourceAllocations` specification field to set specific resource requests for a `Restic` pod.
|
||||
|
||||
include::snippets/about-restic-deprecation.adoc[leveloffset=+1]
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="oadp-pod-crash-resource-request-velero_{context}"]
|
||||
= Setting resource requests for a Velero pod
|
||||
|
||||
[role="_abstract"]
|
||||
You can use the `configuration.velero.podConfig.resourceAllocations` specification field in the `oadp_v1alpha1_dpa.yaml` file to set specific resource requests for a `Velero` pod.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="oadp-restic-restore-failing-psa-policy_{context}"]
|
||||
= Troubleshooting restic restore partially failed issue on {ocp} 4.14 due to changed PSA policy
|
||||
|
||||
[role="_abstract"]
|
||||
{ocp} 4.14 enforces a Pod Security Admission (PSA) policy that can hinder the readiness of pods during a Restic restore process.
|
||||
|
||||
If a `SecurityContextConstraints` (SCC) resource is not found when a pod is created, and the PSA policy on the pod is not set up to meet the required standards, pod admission is denied.
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="restic-timeout_{context}"]
|
||||
= Implementing restic timeout
|
||||
|
||||
[role="_abstract"]
|
||||
The `spec.configuration.nodeAgent.timeout` parameter defines the Restic timeout. The default value is `1h`.
|
||||
|
||||
Use the Restic `timeout` parameter in the `nodeAgent` section for the following scenarios:
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="velero-default-item-operation-timeout_{context}"]
|
||||
= Implementing velero default item operation timeout
|
||||
|
||||
[role="_abstract"]
|
||||
The `defaultItemOperationTimeout` setting defines how long to wait on asynchronous `BackupItemActions` and `RestoreItemActions` to complete before timing out. The default value is `1h`.
|
||||
|
||||
Use the `defaultItemOperationTimeout` for the following scenarios:
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="velero-timeout_{context}"]
|
||||
= Implementing velero resource timeout
|
||||
|
||||
[role="_abstract"]
|
||||
`resourceTimeout` defines how long to wait for several Velero resources before timeout occurs, such as Velero custom resource definition (CRD) availability, `volumeSnapshot` deletion, and repository availability. The default is `10m`.
|
||||
|
||||
Use the `resourceTimeout` for the following scenarios:
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="viewing-metrics-observe-ui_{context}"]
|
||||
= Viewing metrics using the Observe UI
|
||||
|
||||
[role="_abstract"]
|
||||
You can view metrics in the {product-title} web console from the *Administrator* or *Developer* perspective, which must have access to the `openshift-adp` project.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -7,7 +7,9 @@
|
||||
[id="resolving-backup-storage-contains-invalid-directories-issue_{context}"]
|
||||
= Resolving invalid directories in backup storage
|
||||
|
||||
[role="_abstract"]
|
||||
The object storage contains top-level directories that are not Velero directories. The `Velero` pod log displays the following error message:
|
||||
|
||||
[source,text]
|
||||
----
|
||||
Backup storage contains invalid top-level directories.
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="resolving-incorrect-aws-credentials-issue_{context}"]
|
||||
= Resolving incorrect {aws-short} credentials
|
||||
|
||||
[role="_abstract"]
|
||||
If the `credentials-velero` file that is used to create the `Secret` object is incorrectly formatted, multiple errors might occur, including the following examples:
|
||||
|
||||
* The `oadp-aws-registry` pod log displays the following error message:
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="resolving-oadp-operator-fails-silently-issue_{context}"]
|
||||
= Resolving silent failure of the OADP Operator
|
||||
|
||||
[role="_abstract"]
|
||||
The S3 buckets of an OADP Operator might be empty, but when you run the command `oc get po -n <oadp_operator_namespace>`, you see that the Operator has a status of `Running`.
|
||||
|
||||
In such a case, the Operator is said to have _failed silently_ because it incorrectly reports that it is running. The problem is caused when cloud credentials provide insufficient permissions.
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="restic-backup-cr-cannot-be-recreated-after-bucket-is-emptied_{context}"]
|
||||
= Troubleshooting Restic Backup CR issue that cannot be re-created after bucket is emptied
|
||||
|
||||
[role="_abstract"]
|
||||
Velero does not re-create or update the Restic repository from the `ResticRepository` manifest if the Restic directories are deleted from object storage. For more information, see link:https://github.com/vmware-tanzu/velero/issues/4421[Velero issue 4421].
|
||||
|
||||
If you create a Restic `Backup` CR for a namespace, empty the object storage bucket, and then re-create the `Backup` CR for the same namespace, the re-created `Backup` CR fails. In this case, the `velero` pod log displays the following error message:
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="restic-permission-error-for-nfs-data-volumes-with-root-squash-enabled_{context}"]
|
||||
= Troubleshooting Restic permission errors for NFS data volumes
|
||||
|
||||
[role="_abstract"]
|
||||
If your NFS data volumes have the `root_squash` parameter enabled, `Restic` maps set to the `nfsnobody` value, and do not have permission to create backups, the Restic` pod log displays the following error message:
|
||||
|
||||
.Sample error
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="setting-resource-requests-for-a-nodeagent-pod_{context}"]
|
||||
= Setting resource requests for a nodeAgent pod
|
||||
|
||||
[role="_abstract"]
|
||||
You can use the `configuration.nodeAgent.podConfig.resourceAllocations` specification field to set specific resource requests for a `nodeAgent` pod.
|
||||
|
||||
include::snippets/about-restic-deprecation.adoc[leveloffset=+1]
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="troubleshooting-backup-cr-cannot-retrieve-volume-issue_{context}"]
|
||||
= Troubleshooting issue where backup CR cannot retrieve volume
|
||||
|
||||
[role="_abstract"]
|
||||
If the persistent volume (PV) and the snapshot locations are in different regions, the `Backup` custom resource (CR) displays the following error message:
|
||||
|
||||
.Sample error
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="troubleshooting-backup-cr-status-remains-in-partiallyfailed-issue_{context}"]
|
||||
= Troubleshooting issue where backup CR status remains partially failed
|
||||
|
||||
[role="_abstract"]
|
||||
The status of a `Backup` CR without Restic in use remains in the `PartiallyFailed` phase and is not completed. A snapshot of the affiliated PVC is not created.
|
||||
|
||||
If the backup created based on the CSI snapshot class is missing a label, the CSI snapshot plugin fails to create a snapshot. As a result, the `Velero` pod logs an error similar to the following message:
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
[id="troubleshooting-backup-cr-status-remains-in-progress-issue_{context}"]
|
||||
= Troubleshooting issue where backup CR status remains in progress
|
||||
|
||||
[role="_abstract"]
|
||||
If a backup is interrupted, it cannot be resumed, and the status of a `Backup` customer resource (CR) remains in the `InProgress` phase and does not complete.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="oadp-running-must-gather_{context}"]
|
||||
= Using the must-gather tool
|
||||
|
||||
[role="_abstract"]
|
||||
You can run the `must-gather` tool with the following options. To use an option, add a flag corresponding to that option in the `must-gather` command.
|
||||
|
||||
Default configuration:: This configuration collects pod logs, {oadp-short}, and `Velero` custom resource (CR) information for all namespaces where the {oadp-short} Operator is installed.
|
||||
|
||||
@@ -10,15 +10,15 @@
|
||||
[cols="3", options="header"]
|
||||
|===
|
||||
|OADP version |Velero version |{product-title} version
|
||||
| 1.3.0 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
|
||||
| 1.3.1 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
|
||||
| 1.3.2 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
|
||||
| 1.3.3 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
|
||||
| 1.3.4 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
|
||||
| 1.3.5 | link:https://{velero-domain}/docs/v1.12/[1.12] | 4.12-4.15
|
||||
| 1.4.0 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14-4.18
|
||||
| 1.4.1 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14-4.18
|
||||
| 1.4.2 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14-4.18
|
||||
| 1.4.3 | link:https://{velero-domain}/docs/v1.14/[1.14] | 4.14-4.18
|
||||
| 1.5.0 | link:https://{velero-domain}/docs/v1.16/[1.16] | 4.19
|
||||
| 1.3.0 | {velero-1.12} | 4.12-4.15
|
||||
| 1.3.1 | {velero-1.12} | 4.12-4.15
|
||||
| 1.3.2 | {velero-1.12} | 4.12-4.15
|
||||
| 1.3.3 | {velero-1.12} | 4.12-4.15
|
||||
| 1.3.4 | {velero-1.12} | 4.12-4.15
|
||||
| 1.3.5 | {velero-1.12} | 4.12-4.15
|
||||
| 1.4.0 | {velero-1.14} | 4.14-4.18
|
||||
| 1.4.1 | {velero-1.14} | 4.14-4.18
|
||||
| 1.4.2 | {velero-1.14} | 4.14-4.18
|
||||
| 1.4.3 | {velero-1.14} | 4.14-4.18
|
||||
| 1.5.0 | {velero-1.16} | 4.19
|
||||
|===
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
[id="velero-obtaining-by-accessing-binary_{context}"]
|
||||
= Accessing the Velero binary in the Velero deployment in the cluster
|
||||
|
||||
[role="_abstract"]
|
||||
You can use a shell command to access the Velero binary in the Velero deployment in the cluster.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -6,7 +6,8 @@
|
||||
[id="velero-obtaining-by-downloading_{context}"]
|
||||
= Downloading the Velero CLI tool
|
||||
|
||||
You can download and install the Velero CLI tool by following the instructions on the link:https://{velero-domain}/docs/v{velero-version}/basic-install/#install-the-cli[Velero documentation page]. The page includes instructions for the following options:
|
||||
[role="_abstract"]
|
||||
You can download and install the Velero CLI tool by following the instructions on the Velero documentation page. The page includes instructions for the following options:
|
||||
|
||||
* macOS by using Homebrew
|
||||
* GitHub
|
||||
@@ -19,6 +20,6 @@ You can download and install the Velero CLI tool by following the instructions o
|
||||
|
||||
.Procedure
|
||||
|
||||
. Open a browser and navigate to link:https://{velero-domain}/docs/v{velero-version}/basic-install/#install-the-cli["Install the CLI" on the Velero website].
|
||||
. Open a browser and navigate to {velero-cli-install}.
|
||||
. Follow the appropriate procedure for macOS, GitHub, or Windows.
|
||||
. Download the Velero version appropriate for your version of OADP and {product-title}.
|
||||
|
||||
@@ -8,6 +8,7 @@
|
||||
[id="workaround-for-openshift-adp-controller-segmentation-fault_{context}"]
|
||||
= Workaround for OpenShift ADP Controller segmentation fault
|
||||
|
||||
[role="_abstract"]
|
||||
If you configure a Data Protection Application (DPA) with both `cloudstorage` and `restic` enabled, the `openshift-adp-controller-manager` pod crashes and restarts indefinitely until the pod fails with a crash loop segmentation fault.
|
||||
|
||||
Define either `velero` or `cloudstorage` when you configure a DPA. Otherwise, the `openshift-adp-controller-manager` pod fails with a crash loop segmentation fault due to the following settings:
|
||||
|
||||
Reference in New Issue
Block a user