故障排除 - OADP 应用程序备份和还原 | 备份和还原 | OpenShift Container Platform 4.17

下载 Velero CLI 工具
- OADP-Velero-OpenShift 容器平台版本关系
访问集群中 Velero 部署中的 Velero 二进制文件
使用 OpenShift CLI 工具调试 Velero 资源
使用 Velero CLI 工具调试 Velero 资源
由于缺少内存或 CPU 而导致 Pod 崩溃或重启
- 为 Velero Pod 设置资源请求
- 为 Restic Pod 设置资源请求
当 StorageClass 为 NFS 时，PodVolumeRestore 无法完成
Velero 和准入 Webhook 的问题
安装问题
- 备份存储包含无效目录
- AWS 凭据不正确
OADP 运算符问题
- OADP 运算符静默失败
OADP 超时
备份和恢复 CR 问题
Restic 问题
使用 must-gather 工具
- 使用 must-gather 进行不安全的 TLS 连接
- 使用 must-gather 工具时组合选项
OADP 监控

您可以使用OpenShift CLI 工具或Velero CLI 工具调试 Velero 自定义资源 (CR)。Velero CLI 工具提供更详细的日志和信息。

您可以检查安装问题、备份和恢复 CR 问题以及Restic 问题。

您可以使用must-gather工具收集日志和 CR 信息。

您可以通过以下方式获取 Velero CLI 工具：

下载 Velero CLI 工具
访问集群中 Velero 部署中的 Velero 二进制文件

下载 Velero CLI 工具

您可以按照Velero 文档页面上的说明下载并安装 Velero CLI 工具。

该页面包含以下说明：

使用 Homebrew 安装 macOS
GitHub
使用 Chocolatey 安装 Windows

先决条件

您已访问 Kubernetes 集群（v1.16 或更高版本），并启用了 DNS 和容器网络。
您已在本地安装了 kubectl。

步骤

打开浏览器并导航到 Velero 网站上的 "安装 CLI"。
按照适用于 macOS、GitHub 或 Windows 的相应步骤操作。
下载适合您的 OADP 和 OpenShift Container Platform 版本的 Velero 版本。

OADP-Velero-OpenShift Container Platform 版本关系

OADP 版本	Velero 版本	OpenShift Container Platform 版本
1.1.0	1.9	4.9 及更高版本
1.1.1	1.9	4.9 及更高版本
1.1.2	1.9	4.9 及更高版本
1.1.3	1.9	4.9 及更高版本
1.1.4	1.9	4.9 及更高版本
1.1.5	1.9	4.9 及更高版本
1.1.6	1.9	4.11 及更高版本
1.1.7	1.9	4.11 及更高版本
1.2.0	1.11	4.11 及更高版本
1.2.1	1.11	4.11 及更高版本
1.2.2	1.11	4.11 及更高版本
1.2.3	1.11	4.11 及更高版本
1.3.0	1.12	4.10 - 4.15
1.3.1	1.12	4.10 - 4.15
1.3.2	1.12	4.10 - 4.15
1.4.0	1.14	4.14 及更高版本
1.4.1	1.14	4.14 及更高版本

访问集群中 Velero 部署中的 Velero 二进制文件

您可以使用 shell 命令访问集群中 Velero 部署中的 Velero 二进制文件。

先决条件

您的 DataProtectionApplication 自定义资源状态为 Reconcile complete。

步骤

输入以下命令设置所需的别名

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

使用 OpenShift CLI 工具调试 Velero 资源

您可以通过检查 Velero 自定义资源 (CR) 和 Velero Pod 日志来调试备份或恢复失败。

Velero CR

使用 oc describe 命令检索与 Backup 或 Restore CR 相关的警告和错误摘要。

$ oc describe <velero_cr> <cr_name>

Velero Pod 日志

使用 oc logs 命令检索 Velero Pod 日志。

$ oc logs pod/<velero>

Velero Pod 调试日志

您可以在 DataProtectionApplication 资源中指定 Velero 日志级别，如下例所示。

此选项从 OADP 1.0.3 开始可用。

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

以下 logLevel 值可用：

trace
debug
info
warning
error
fatal
panic

建议大多数日志使用 debug。

使用 Velero CLI 工具调试 Velero 资源

您可以使用 Velero CLI 工具调试 Backup 和 Restore 自定义资源 (CR) 并检索日志。

Velero CLI 工具提供比 OpenShift CLI 工具更详细的信息。

语法

使用 oc exec 命令运行 Velero CLI 命令。

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

示例

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

帮助选项

使用 velero --help 选项列出所有 Velero CLI 命令。

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

describe 命令

使用 velero describe 命令检索与 Backup 或 Restore CR 相关的警告和错误摘要。

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

示例

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

velero describe 请求的输出中将显示以下类型的恢复错误和警告：

Velero：与 Velero 本身操作相关的消息列表，例如，与连接到云、读取备份文件等相关的消息。
Cluster：与备份或恢复集群范围资源相关的消息列表。
Namespaces：与备份或恢复存储在命名空间中的资源相关的消息列表。

这些类别中的一项或多项错误会导致 Restore 操作的状态为 PartiallyFailed 而不是 Completed。警告不会导致完成状态发生变化。

对于资源特定的错误，即 Cluster 和 Namespaces 错误，restore describe --details 输出包含一个资源列表，其中列出了 Velero 成功恢复的所有资源。对于任何具有此类错误的资源，请检查该资源是否实际位于集群中。
如果 describe 命令的输出中存在 Velero 错误，但没有资源特定的错误，则恢复可能在没有实际恢复工作负载问题的情况下完成，但请仔细验证恢复后的应用程序。

例如，如果输出包含 PodVolumeRestore 或节点代理相关的错误，请检查 PodVolumeRestores 和 DataDownloads 的状态。如果这些都没有失败或仍在运行，则卷数据可能已完全恢复。

logs 命令

使用 velero logs 命令检索 Backup 或 Restore CR 的日志。

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

示例

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

由于内存或 CPU 不足导致 Pod 崩溃或重启

如果由于内存或 CPU 不足导致 Velero 或 Restic Pod 崩溃，您可以为这些资源设置特定的资源请求。

其他资源

CPU 和内存需求

为 Velero Pod 设置资源请求

您可以使用 oadp_v1alpha1_dpa.yaml 文件中的 configuration.velero.podConfig.resourceAllocations 规范字段为 Velero Pod 设置特定的资源请求。

步骤

在 YAML 文件中设置 cpu 和 memory 资源请求。

Velero 文件示例

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
configuration:
  velero:
    podConfig:
      resourceAllocations: (1)
        requests:
          cpu: 200m
          memory: 256Mi

1	列出的 `resourceAllocations` 用于平均使用情况。

为 Restic Pod 设置资源请求

您可以使用 configuration.restic.podConfig.resourceAllocations 规范字段为 Restic Pod 设置特定的资源请求。

步骤

在 YAML 文件中设置 cpu 和 memory 资源请求。

Restic 文件示例

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
configuration:
  restic:
    podConfig:
      resourceAllocations: (1)
        requests:
          cpu: 1000m
          memory: 16Gi

1	列出的 `resourceAllocations` 用于平均使用情况。

资源请求字段的值必须遵循与 Kubernetes 资源需求相同的格式。此外，如果您未指定 configuration.velero.podConfig.resourceAllocations 或 configuration.restic.podConfig.resourceAllocations，则 Velero Pod 或 Restic Pod 的默认 resources 规范如下所示：

requests:
  cpu: 500m
  memory: 128Mi

当 StorageClass 为 NFS 时，PodVolumeRestore 无法完成

当使用 Restic 或 Kopia 进行 NFS 恢复时，如果有多个卷，则恢复操作将失败。PodVolumeRestore 可能会失败并显示以下错误，或者在最终失败之前一直尝试恢复。

错误消息

Velero: pod volume restore failed: data path restore failed: \
Failed to run kopia restore: Failed to copy snapshot data to the target: \
restore error: copy file: error creating file: \
open /host_pods/b4d...6/volumes/kubernetes.io~nfs/pvc-53...4e5/userdata/base/13493/2681: \
no such file or directory

原因

要恢复的两个卷的 NFS 挂载路径不唯一。因此，velero 锁文件在恢复期间使用 NFS 服务器上的相同文件，导致 PodVolumeRestore 失败。

解决方案

您可以通过为每个卷设置唯一的 pathPattern 来解决此问题，同时在 deploy/class.yaml 文件中定义 nfs-subdir-external-provisioner 的 StorageClass。使用以下 nfs-subdir-external-provisioner StorageClass 示例：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  pathPattern: "${.PVC.namespace}/${.PVC.annotations.nfs.io/storage-path}" (1)
  onDelete: delete

1	使用 `PVC` 元数据（例如标签、注释、名称或命名空间）指定创建目录路径的模板。要指定元数据，请使用 `${.PVC.<metadata>}`。例如，要命名一个文件夹：`<pvc-namespace>-<pvc-name>`，请使用 `${.PVC.namespace}-${.PVC.name}` 作为 `pathPattern`。

Velero 和准入 Webhook 的问题

Velero 在恢复期间解决准入 Webhook 问题的能力有限。如果您有使用准入 Webhook 的工作负载，您可能需要使用额外的 Velero 插件或更改恢复工作负载的方式。

通常，使用准入 Webhook 的工作负载需要您首先创建特定类型的资源。如果您的工作负载具有子资源，则尤其如此，因为准入 Webhook 通常会阻止子资源。

例如，创建或恢复顶级对象（例如 service.serving.knative.dev）通常会自动创建子资源。如果首先执行此操作，则无需使用 Velero 来创建和恢复这些资源。这避免了 Velero 可能使用的准入 Webhook 阻止子资源的问题。

使用准入 Webhook 的 Velero 备份的恢复解决方法

本节介绍使用准入 Webhook 的几种类型的 Velero 备份的资源恢复所需的附加步骤。

恢复 Knative 资源

您可能会遇到使用 Velero 备份使用准入 Webhook 的 Knative 资源时的问题。

在备份和恢复使用准入 Webhook 的 Knative 资源时，您可以通过首先恢复顶级Service资源来避免此类问题。

步骤

恢复顶级service.serving.knative.dev Service资源

$ velero restore <restore_name> \
  --from-backup=<backup_name> --include-resources \
  service.serving.knavtive.dev

恢复 IBM AppConnect 资源

如果您在使用 Velero 恢复具有准入 Webhook 的 IBM® AppConnect 资源时遇到问题，您可以运行此过程中的检查。

步骤

检查集群中是否存在任何kind: MutatingWebhookConfiguration 的变异准入插件
```
$ oc get mutatingwebhookconfigurations
```
检查每个kind: MutatingWebhookConfiguration 的 YAML 文件，以确保其规则不会阻止正在遇到问题的对象的创建。更多信息，请参见官方 Kubernetes 文档。
检查备份时使用的type: Configuration.appconnect.ibm.com/v1beta1 中的任何spec.version 是否受已安装的 Operator 支持。

OADP 插件已知问题

以下部分描述了 OpenShift 数据保护 API (OADP) 插件中的已知问题

由于缺少密钥，Velero 插件在镜像流备份期间发生 panic

当备份和备份存储位置 (BSL) 在数据保护应用程序 (DPA) 的范围之外管理时，OADP 控制器（即 DPA 调和）不会创建相关的oadp-<bsl_name>-<bsl_provider>-registry-secret。

运行备份时，OpenShift Velero 插件在镜像流备份上发生 panic，并显示以下 panic 错误

024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item"
backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io,
namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked:
runtime error: index out of range with length 1, stack trace: goroutine 94…

避免 panic 错误的解决方法

要避免 Velero 插件 panic 错误，请执行以下步骤

使用相关标签标记自定义 BSL。

$ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl

标记 BSL 后，等待 DPA 调和。

您可以通过对 DPA 本身进行任何微小的更改来强制调和。
当 DPA 调和后，确认已创建相关的oadp-<bsl_name>-<bsl_provider>-registry-secret，并且正确的注册表数据已填充到其中。
```
$ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
```

OpenShift ADP 控制器段错误

如果您同时启用cloudstorage 和restic 配置 DPA，则openshift-adp-controller-manager pod 将无限期地崩溃和重启，直到 pod 出现崩溃循环段错误。

您只能定义velero 或cloudstorage 之一，因为它们是互斥字段。

如果您同时定义了velero 和cloudstorage，则openshift-adp-controller-manager 会失败。
如果您既没有定义velero 也没有定义cloudstorage，则openshift-adp-controller-manager 会失败。

有关此问题的更多信息，请参见OADP-1054。

OpenShift ADP 控制器段错误解决方法

配置 DPA 时，必须定义velero 或cloudstorage 之一。如果您在 DPA 中同时定义这两个 API，则openshift-adp-controller-manager pod 将出现崩溃循环段错误。

Velero 插件返回“received EOF, stopping recv loop”消息

Velero 插件作为单独的进程启动。Velero 操作完成后（无论成功与否），它们都会退出。在调试日志中收到received EOF, stopping recv loop 消息表示插件操作已完成。这并不意味着发生了错误。

其他资源

安装问题

安装数据保护应用程序时，您可能会遇到由使用无效目录或不正确的凭据引起的问题。

备份存储包含无效目录

Velero pod 日志显示错误消息Backup storage contains invalid top-level directories。

原因

对象存储包含不是 Velero 目录的顶级目录。

解决方案

如果对象存储不是专用于 Velero 的，则必须通过在DataProtectionApplication 清单中设置spec.backupLocations.velero.objectStorage.prefix 参数来为存储桶指定前缀。

AWS 凭据不正确

oadp-aws-registry pod 日志显示错误消息InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records.

Velero pod 日志显示错误消息NoCredentialProviders: no valid providers in chain。

原因

用于创建Secret对象的credentials-velero文件格式不正确。

解决方案

确保credentials-velero文件格式正确，如下例所示

示例credentials-velero文件

[default] (1)
aws_access_key_id=AKIAIOSFODNN7EXAMPLE (2)
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

1	AWS 默认配置文件。
2	不要用引号（`"`，`'`）括住值。

OADP Operator 问题

OpenShift 数据保护 API (OADP) Operator 可能会遇到它无法解决的问题引起的问题。

OADP Operator 悄悄失败

OADP Operator 的 S3 存储桶可能为空，但是当您运行命令oc get po -n <OADP_Operator_namespace>时，您会看到 Operator 的状态为Running。在这种情况下，Operator 被认为是“悄悄失败”，因为它错误地报告它正在运行。

原因

此问题是由云凭据提供权限不足引起的。

解决方案

检索备份存储位置 (BSL) 列表，并检查每个 BSL 的清单是否有凭据问题。

步骤

运行以下命令之一以检索 BSL 列表

使用 OpenShift CLI

$ oc get backupstoragelocations.velero.io -A

使用 Velero CLI

$ velero backup-location get -n <OADP_Operator_namespace>

使用 BSL 列表，运行以下命令显示每个 BSL 的清单，并检查每个清单是否有错误。
```
$ oc get backupstoragelocations.velero.io -n <namespace> -o yaml
```

示例结果

apiVersion: v1
items:
- apiVersion: velero.io/v1
  kind: BackupStorageLocation
  metadata:
    creationTimestamp: "2023-11-03T19:49:04Z"
    generation: 9703
    name: example-dpa-1
    namespace: openshift-adp-operator
    ownerReferences:
    - apiVersion: oadp.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: DataProtectionApplication
      name: example-dpa
      uid: 0beeeaff-0287-4f32-bcb1-2e3c921b6e82
    resourceVersion: "24273698"
    uid: ba37cd15-cf17-4f7d-bf03-8af8655cea83
  spec:
    config:
      enableSharedConfig: "true"
      region: us-west-2
    credential:
      key: credentials
      name: cloud-credentials
    default: true
    objectStorage:
      bucket: example-oadp-operator
      prefix: example
    provider: aws
  status:
    lastValidationTime: "2023-11-10T22:06:46Z"
    message: "BackupStorageLocation \"example-dpa-1\" is unavailable: rpc
      error: code = Unknown desc = WebIdentityErr: failed to retrieve credentials\ncaused
      by: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n\tstatus
      code: 403, request id: d3f2e099-70a0-467b-997e-ff62345e3b54"
    phase: Unavailable
kind: List
metadata:
  resourceVersion: ""

OADP 超时

延长超时允许复杂或资源密集型进程成功完成而不会过早终止。此配置可以降低错误、重试或失败的可能性。

确保以逻辑方式平衡超时扩展，以免配置过长的超时，这可能会隐藏进程中的潜在问题。仔细考虑并监控满足进程需求和整体系统性能的适当超时值。

以下是各种 OADP 超时，以及如何以及何时实现这些参数的说明

Restic 超时

spec.configuration.nodeAgent.timeout 参数定义 Restic 超时。默认值为1h。

在以下情况下，使用nodeAgent 部分中的 Restic timeout 参数

对于总 PV 数据使用量超过 500GB 的 Restic 备份。

如果备份超时并出现以下错误

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete"

步骤

编辑 `DataProtectionApplication` 自定义资源 (CR) 清单文件中 `spec.configuration.nodeAgent.timeout` 块中的值，如下例所示

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: <dpa_name>
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: restic
      timeout: 1h
# ...

Velero 资源超时

`resourceTimeout` 定义了在超时发生之前等待多个 Velero 资源的时间，例如 Velero 自定义资源定义 (CRD) 可用性、`volumeSnapshot` 删除和存储库可用性。默认值为 `10m`。

在以下情况下使用 `resourceTimeout`

对于总 PV 数据使用量超过 1TB 的备份。此参数用作 Velero 尝试清理或删除容器存储接口 (CSI) 快照（在将备份标记为完成之前）时的超时值。
- 此清理的一个子任务尝试修补 VSC，此超时可用于该任务。
创建或确保备份存储库已准备好用于 Restic 或 Kopia 的基于文件系统的备份。
在还原备份中的自定义资源 (CR) 或资源之前，检查 Velero CRD 是否在集群中可用。

步骤

编辑 `DataProtectionApplication` CR 清单文件中 `spec.configuration.velero.resourceTimeout` 块中的值，如下例所示

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: <dpa_name>
spec:
  configuration:
    velero:
      resourceTimeout: 10m
# ...

数据移动器超时

`timeout` 是用户提供的完成 `VolumeSnapshotBackup` 和 `VolumeSnapshotRestore` 的超时时间。默认值为 `10m`。

在以下情况下使用数据移动器 `timeout`

如果 `VolumeSnapshotBackups` (VSB) 和 `VolumeSnapshotRestores` (VSR) 的创建在 10 分钟后超时。
对于总 PV 数据使用量超过 500GB 的大规模环境。将超时设置为 `1h`。
使用 `VolumeSnapshotMover` (VSM) 插件。
仅适用于 OADP 1.1.x。

步骤

编辑 `DataProtectionApplication` CR 清单文件中 `spec.features.dataMover.timeout` 块中的值，如下例所示

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: <dpa_name>
spec:
  features:
    dataMover:
      timeout: 10m
# ...

CSI 快照超时

`CSISnapshotTimeout` 指定创建期间等待的时间，直到 `CSI VolumeSnapshot` 状态变为 `ReadyToUse`，然后再返回超时错误。默认值为 `10m`。

在以下情况下使用 `CSISnapshotTimeout`

使用 CSI 插件。
对于可能需要超过 10 分钟才能创建快照的超大存储卷。如果在日志中发现超时，请调整此超时时间。

通常，`CSISnapshotTimeout` 的默认值不需要调整，因为默认设置可以适应大型存储卷。

步骤

编辑 `Backup` CR 清单文件中 `spec.csiSnapshotTimeout` 块中的值，如下例所示

apiVersion: velero.io/v1
kind: Backup
metadata:
 name: <backup_name>
spec:
 csiSnapshotTimeout: 10m
# ...

Velero 默认项目操作超时

`defaultItemOperationTimeout` 定义了在超时之前等待异步 `BackupItemActions` 和 `RestoreItemActions` 完成的时间。默认值为 `1h`。

在以下情况下使用 `defaultItemOperationTimeout`

仅适用于数据移动器 1.2.x。
指定特定备份或还原应等待异步操作完成的时间。在 OADP 功能的上下文中，此值用于容器存储接口 (CSI) 数据移动器功能中涉及的异步操作。
当使用 `defaultItemOperationTimeout` 在数据保护应用程序 (DPA) 中定义 `defaultItemOperationTimeout` 时，它适用于备份和还原操作。您可以使用 `itemOperationTimeout` 来仅定义这些 CR 的备份或还原，如下面的“项目操作超时 - 还原”和“项目操作超时 - 备份”部分所述。

步骤

编辑 `DataProtectionApplication` CR 清单文件中 `spec.configuration.velero.defaultItemOperationTimeout` 块中的值，如下例所示

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: <dpa_name>
spec:
  configuration:
    velero:
      defaultItemOperationTimeout: 1h
# ...

项目操作超时 - 还原

`ItemOperationTimeout` 指定用于等待 `RestoreItemAction` 操作的时间。默认值为 `1h`。

在以下情况下使用还原 `ItemOperationTimeout`

仅适用于数据移动器 1.2.x。
对于数据移动器向 `BackupStorageLocation` 上传和下载数据。如果在达到超时时还原操作未完成，则将其标记为失败。如果由于存储卷大小较大而导致数据移动器操作因超时问题而失败，则可能需要增加此超时设置。

步骤

编辑 `Restore` CR 清单文件中 `Restore.spec.itemOperationTimeout` 块中的值，如下例所示

apiVersion: velero.io/v1
kind: Restore
metadata:
 name: <restore_name>
spec:
 itemOperationTimeout: 1h
# ...

项目操作超时 - 备份

`ItemOperationTimeout` 指定用于等待异步 `BackupItemAction` 操作的时间。默认值为 `1h`。

在以下情况下使用备份 `ItemOperationTimeout`

仅适用于数据移动器 1.2.x。
对于数据移动器向 `BackupStorageLocation` 上传和下载数据。如果在达到超时时备份操作未完成，则将其标记为失败。如果由于存储卷大小较大而导致数据移动器操作因超时问题而失败，则可能需要增加此超时设置。

步骤

编辑 `Backup` CR 清单文件中 `Backup.spec.itemOperationTimeout` 块中的值，如下例所示

apiVersion: velero.io/v1
kind: Backup
metadata:
 name: <backup_name>
spec:
 itemOperationTimeout: 1h
# ...

备份和还原 CR 问题

您可能会遇到这些常见的 `Backup` 和 `Restore` 自定义资源 (CR) 问题。

备份 CR 无法检索卷

`Backup` CR 显示错误消息 `InvalidVolume.NotFound: The volume ‘vol-xxxx’ does not exist`。

原因

持久卷 (PV) 和快照位置位于不同的区域。

解决方案

编辑 `DataProtectionApplication` 清单文件中 `spec.snapshotLocations.velero.config.region` 密钥的值，以便快照位置与 PV 位于同一区域。
创建一个新的 `Backup` CR。

备份 CR 状态保持进行中

`Backup` CR 的状态保持在 `InProgress` 阶段并且未完成。

原因

如果备份中断，则无法恢复。

解决方案

检索 `Backup` CR 的详细信息

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

删除 `Backup` CR
```
$ oc delete backups.velero.io <backup> -n openshift-adp
```
您无需清理备份位置，因为进行中的 `Backup` CR 尚未将文件上传到对象存储。
创建一个新的 `Backup` CR。

查看 Velero 备份详细信息

$ velero backup describe <backup-name> --details

备份 CR 状态保持部分失败

未使用 Restic 的 `Backup` CR 的状态保持在 `PartiallyFailed` 阶段并且未完成。未创建关联 PVC 的快照。

原因

如果备份基于 CSI 快照类创建，但缺少标签，则 CSI 快照插件将无法创建快照。结果，Velero Pod 会记录类似于以下内容的错误

time="2023-02-17T16:33:13Z" level=error msg="Error backing up item" backup=openshift-adp/user1-backup-check5 error="error executing custom action (groupResource=persistentvolumeclaims, namespace=busy1, name=pvc1-user1): rpc error: code = Unknown desc = failed to get volumesnapshotclass for storageclass ocs-storagecluster-ceph-rbd: failed to get volumesnapshotclass for provisioner openshift-storage.rbd.csi.ceph.com, ensure that the desired volumesnapshot class has the velero.io/csi-volumesnapshot-class label" logSource="/remote-source/velero/app/pkg/backup/backup.go:417" name=busybox-79799557b5-vprq

解决方案

删除 `Backup` CR

$ oc delete backups.velero.io <backup> -n openshift-adp

如有必要，请清理BackupStorageLocation 上存储的数据以释放空间。

为VolumeSnapshotClass 对象应用标签velero.io/csi-volumesnapshot-class=true

$ oc label volumesnapshotclass/<snapclass_name> velero.io/csi-volumesnapshot-class=true

创建一个新的 `Backup` CR。

Restic 问题

使用 Restic 备份应用程序时，可能会遇到以下问题。

启用了 root_squash 的 NFS 数据卷的 Restic 权限错误

Restic Pod 日志显示错误消息：controller=pod-volume-backup error="fork/exec/usr/bin/restic: permission denied"。

原因

如果您的 NFS 数据卷启用了root_squash，Restic 将映射到nfsnobody，并且没有权限创建备份。

解决方案

您可以通过为Restic 创建一个补充组并将组 ID 添加到DataProtectionApplication 清单中来解决此问题

在 NFS 数据卷上为Restic 创建一个补充组。
在 NFS 目录上设置setgid 位，以便继承组所有权。

添加spec.configuration.nodeAgent.supplementalGroups 参数和组 ID 到DataProtectionApplication 清单，如下例所示

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
# ...
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: restic
      supplementalGroups:
      - <group_id> (1)
# ...

指定补充组 ID。

等待Restic Pod 重启，以便应用更改。

清空桶后无法重新创建 Restic Backup CR

如果您为命名空间创建 Restic Backup CR，清空对象存储桶，然后为同一命名空间重新创建Backup CR，则重新创建的Backup CR 将失败。

velero Pod 日志显示以下错误消息：stderr=Fatal: unable to open config file: Stat: The specified key does not exist.\nIs there a repository at the following location?。

原因

如果从对象存储中删除了 Restic 目录，Velero 不会从ResticRepository 清单中重新创建或更新 Restic 存储库。有关更多信息，请参见Velero 问题 4421。

解决方案

通过运行以下命令删除命名空间中相关的 Restic 存储库

$ oc delete resticrepository openshift-adp <name_of_the_restic_repository>

在以下错误日志中，mysql-persistent 是有问题的 Restic 存储库。为了清晰起见，存储库名称以斜体显示。

 time="2021-12-29T18:29:14Z" level=info msg="1 errors
 encountered backup up item" backup=velero/backup65
 logSource="pkg/backup/backup.go:431" name=mysql-7d99fc949-qbkds
 time="2021-12-29T18:29:14Z" level=error msg="Error backing up item"
 backup=velero/backup65 error="pod volume backup failed: error running
 restic backup, stderr=Fatal: unable to open config file: Stat: The
 specified key does not exist.\nIs there a repository at the following
 location?\ns3:http://minio-minio.apps.mayap-oadp-
 veleo-1234.qe.devcluster.openshift.com/mayapvelerooadp2/velero1/
 restic/mysql-persistent\n: exit status 1" error.file="/remote-source/
 src/github.com/vmware-tanzu/velero/pkg/restic/backupper.go:184"
 error.function="github.com/vmware-tanzu/velero/
 pkg/restic.(*backupper).BackupPodVolumes"
 logSource="pkg/backup/backup.go:435" name=mysql-7d99fc949-qbkds

由于 PSA 策略更改，Restic 还原在 OCP 4.14 上部分失败

OpenShift Container Platform 4.14 实施了 Pod 安全准入 (PSA) 策略，这可能会妨碍 Restic 还原过程中的 Pod 就绪状态。

如果在创建 Pod 时找不到SecurityContextConstraints (SCC) 资源，并且 Pod 上的 PSA 策略未设置为满足所需标准，则会拒绝 Pod 准入。

此问题是由于 Velero 的资源还原顺序造成的。

示例错误

\"level=error\" in line#2273: time=\"2023-06-12T06:50:04Z\"
level=error msg=\"error restoring mysql-869f9f44f6-tp5lv: pods\\\
"mysql-869f9f44f6-tp5lv\\\" is forbidden: violates PodSecurity\\\
"restricted:v1.24\\\": privil eged (container \\\"mysql\\\
" must not set securityContext.privileged=true),
allowPrivilegeEscalation != false (containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.capabilities.drop=[\\\"ALL\\\"]), seccompProfile (pod or containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.seccompProfile.type to \\\
"RuntimeDefault\\\" or \\\"Localhost\\\")\" logSource=\"/remote-source/velero/app/pkg/restore/restore.go:1388\" restore=openshift-adp/todolist-backup-0780518c-08ed-11ee-805c-0a580a80e92c\n
velero container contains \"level=error\" in line#2447: time=\"2023-06-12T06:50:05Z\"
level=error msg=\"Namespace todolist-mariadb,
resource restore error: error restoring pods/todolist-mariadb/mysql-869f9f44f6-tp5lv: pods \\\
"mysql-869f9f44f6-tp5lv\\\" is forbidden: violates PodSecurity \\\"restricted:v1.24\\\": privileged (container \\\
"mysql\\\" must not set securityContext.privileged=true),
allowPrivilegeEscalation != false (containers \\\
"restic-wait\\\",\\\"mysql\\\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.capabilities.drop=[\\\"ALL\\\"]), seccompProfile (pod or containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.seccompProfile.type to \\\
"RuntimeDefault\\\" or \\\"Localhost\\\")\"
logSource=\"/remote-source/velero/app/pkg/controller/restore_controller.go:510\"
restore=openshift-adp/todolist-backup-0780518c-08ed-11ee-805c-0a580a80e92c\n]",

解决方案

在您的 DPA 自定义资源 (CR) 中，检查或设置 Velero 服务器上的restore-resource-priorities 字段，以确保在资源列表中securitycontextconstraints 在pods 之前列出

$ oc get dpa -o yaml

示例 DPA CR

# ...
configuration:
  restic:
    enable: true
  velero:
    args:
      restore-resource-priorities: 'securitycontextconstraints,customresourcedefinitions,namespaces,storageclasses,volumesnapshotclass.snapshot.storage.k8s.io,volumesnapshotcontents.snapshot.storage.k8s.io,volumesnapshots.snapshot.storage.k8s.io,datauploads.velero.io,persistentvolumes,persistentvolumeclaims,serviceaccounts,secrets,configmaps,limitranges,pods,replicasets.apps,clusterclasses.cluster.x-k8s.io,endpoints,services,-,clusterbootstraps.run.tanzu.vmware.com,clusters.cluster.x-k8s.io,clusterresourcesets.addons.cluster.x-k8s.io' (1)
    defaultPlugins:
    - gcp
    - openshift

1	如果您有现有的还原资源优先级列表，请确保将其与完整列表合并。

确保应用程序 Pod 的安全标准一致，如修复部署的 PodSecurity Admission 警告中所述，以防止部署警告。如果应用程序与安全标准不一致，则无论 SCC 如何，都可能发生错误。

此解决方案是临时的，目前正在进行讨论以解决此问题。

其他资源

修复部署的 PodSecurity Admission 警告

使用 must-gather 工具

您可以使用must-gather 工具收集有关 OADP 自定义资源的日志、指标和信息。

必须将must-gather 数据附加到所有客户案例。

您可以使用以下数据收集选项运行must-gather 工具

完整的must-gather 数据收集会收集 Prometheus 指标、Pod 日志和安装了 OADP 运算符的所有命名空间的 Velero CR 信息。
必要的must-gather 数据收集会收集特定时间段（例如，一小时或 24 小时）的 Pod 日志和 Velero CR 信息。不包括 Prometheus 指标和重复日志。
带有超时的must-gather 数据收集。如果有很多失败的Backup CR，则数据收集可能需要很长时间。您可以通过设置超时值来提高性能。
Prometheus 指标数据转储会下载包含 Prometheus 收集的指标数据的存档文件。

先决条件

您必须以具有cluster-admin 角色的用户身份登录到 OpenShift Container Platform 集群。
您必须安装 OpenShift CLI (oc)。
您必须使用带有 OADP 1.4 的 Red Hat Enterprise Linux (RHEL) 9。

步骤

导航到要存储must-gather 数据的目录。
针对以下数据收集选项之一运行oc adm must-gather 命令
- 完整的must-gather 数据收集，包括 Prometheus 指标
  $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4
  数据保存为must-gather/must-gather.tar.gz。您可以将此文件上传到Red Hat 客户门户上的支持案例。
- 必要的must-gather 数据收集，不包括 Prometheus 指标，用于特定时间段
  $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 \ -- /usr/bin/gather_<time>_essential (1)
  1 以小时为单位指定时间。允许的值为1h、6h、24h、72h 或all，例如gather_1h_essential 或gather_all_essential。
- 带有超时的must-gather 数据收集
  $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 \ -- /usr/bin/gather_with_timeout <timeout> (1)
  1 以秒为单位指定超时值。
- Prometheus 指标数据转储
  $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather_metrics_dump
  此操作可能需要很长时间。数据保存为must-gather/metrics/prom_data.tar.gz。

其他资源

收集集群数据

使用不安全的 TLS 连接进行 must-gather

如果使用自定义 CA 证书，则must-gather Pod 将无法获取velero logs/describe 的输出。要将must-gather 工具与不安全的 TLS 连接一起使用，您可以将gather_without_tls 标志传递给must-gather 命令。

步骤

使用以下命令将值设置为true的gather_without_tls 标志传递给must-gather 工具

$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather_without_tls <true/false>

默认情况下，标志值设置为false。将其值设置为true以允许不安全的 TLS 连接。

使用 must-gather 工具时组合选项

目前，无法组合 must-gather 脚本，例如在允许不安全的 TLS 连接的同时指定超时阈值。在某些情况下，您可以通过在 must-gather 命令行上设置内部变量来解决此限制，例如以下示例

$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- skip_tls=true /usr/bin/gather_with_timeout <timeout_value_in_seconds>

在此示例中，在运行gather_with_timeout 脚本之前设置skip_tls 变量。结果是gather_with_timeout 和gather_without_tls 的组合。

您可以通过这种方式指定的其他变量只有以下这些：

logs_since，默认值为72h
request_timeout，默认值为0s

如果DataProtectionApplication 自定义资源 (CR) 配置了 s3Url 和 insecureSkipTLS: true，则由于缺少 CA 证书，CR 无法收集必要的日志。要收集这些日志，请使用以下选项运行must-gather 命令

$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather_without_tls true

OADP 监控

OpenShift Container Platform 提供了一个监控堆栈，允许用户和管理员有效地监控和管理其集群，以及监控和分析在集群上运行的用户应用程序和服务的负载性能，包括在发生事件时接收警报。

其他资源

监控堆栈

OADP 监控设置

OADP 运算符利用 OpenShift Monitoring Stack 提供的 OpenShift 用户工作负载监控来从 Velero 服务端点检索指标。监控堆栈允许使用 OpenShift 指标查询前端创建用户定义的警报规则或查询指标。

启用用户工作负载监控后，可以配置和使用任何与 Prometheus 兼容的第三方 UI（例如 Grafana）来可视化 Velero 指标。

监控指标需要为用户定义的项目启用监控，并创建一个ServiceMonitor 资源，以便从位于openshift-adp 命名空间中的已启用 OADP 服务端点抓取这些指标。

先决条件

您可以使用具有cluster-admin 权限的帐户访问 OpenShift Container Platform 集群。
您已创建集群监控配置映射。

步骤

编辑openshift-monitoring 命名空间中的cluster-monitoring-config ConfigMap 对象
```
$ oc edit configmap cluster-monitoring-config -n openshift-monitoring
```

在data 部分的config.yaml 字段中添加或启用enableUserWorkload 选项

apiVersion: v1
data:
  config.yaml: |
    enableUserWorkload: true (1)
kind: ConfigMap
metadata:
# ...

1	添加此选项或设置为`true`

等待一小段时间，通过检查以下组件是否在openshift-user-workload-monitoring 命名空间中启动并运行来验证用户工作负载监控设置

$ oc get pods -n openshift-user-workload-monitoring

示例输出

NAME                                   READY   STATUS    RESTARTS   AGE
prometheus-operator-6844b4b99c-b57j9   2/2     Running   0          43s
prometheus-user-workload-0             5/5     Running   0          32s
prometheus-user-workload-1             5/5     Running   0          32s
thanos-ruler-user-workload-0           3/3     Running   0          32s
thanos-ruler-user-workload-1           3/3     Running   0          32s

验证openshift-user-workload-monitoring 中是否存在user-workload-monitoring-config ConfigMap。如果存在，则跳过此过程中的其余步骤。

$ oc get configmap user-workload-monitoring-config -n openshift-user-workload-monitoring

示例输出

Error from server (NotFound): configmaps "user-workload-monitoring-config" not found

为用户工作负载监控创建一个user-workload-monitoring-config ConfigMap 对象，并将其保存为2_configure_user_workload_monitoring.yaml 文件名

示例输出

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |

应用2_configure_user_workload_monitoring.yaml 文件

$ oc apply -f 2_configure_user_workload_monitoring.yaml
configmap/user-workload-monitoring-config created

创建 OADP 服务监控器

OADP 提供了一个openshift-adp-velero-metrics-svc 服务，该服务在配置 DPA 时创建。用户工作负载监控使用的服务监控器必须指向定义的服务。

运行以下命令获取有关服务的详细信息

步骤

确保openshift-adp-velero-metrics-svc 服务存在。它应该包含app.kubernetes.io/name=velero 标签，该标签将用作ServiceMonitor 对象的选择器。

$ oc get svc -n openshift-adp -l app.kubernetes.io/name=velero

示例输出

NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
openshift-adp-velero-metrics-svc   ClusterIP   172.30.38.244   <none>        8085/TCP   1h

创建一个与现有服务标签匹配的ServiceMonitor YAML 文件，并将文件保存为3_create_oadp_service_monitor.yaml。服务监控器在openshift-adp-velero-metrics-svc 服务所在的openshift-adp 命名空间中创建。

示例ServiceMonitor 对象

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: oadp-service-monitor
  name: oadp-service-monitor
  namespace: openshift-adp
spec:
  endpoints:
  - interval: 30s
    path: /metrics
    targetPort: 8085
    scheme: http
  selector:
    matchLabels:
      app.kubernetes.io/name: "velero"

应用3_create_oadp_service_monitor.yaml 文件

$ oc apply -f 3_create_oadp_service_monitor.yaml

示例输出

servicemonitor.monitoring.coreos.com/oadp-service-monitor created

验证

使用 OpenShift Container Platform Web 控制台的**管理员**视角确认新的服务监控器处于**运行**状态
1. 导航到**观察** → **目标**页面。
2. 确保**过滤器**未选中，或者**用户**源已选中，并在文本搜索字段中键入openshift-adp。
3. 验证服务监控器的**状态**是否为**运行**。
  
  图 1. OADP 指标目标

创建警报规则

OpenShift Container Platform 监控堆栈允许接收使用警报规则配置的警报。要为 OADP 项目创建警报规则，请使用用户工作负载监控抓取的指标之一。

步骤

创建一个包含示例OADPBackupFailing 警报的PrometheusRule YAML 文件，并将其保存为4_create_oadp_alert_rule.yaml。

示例OADPBackupFailing 警报

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: sample-oadp-alert
  namespace: openshift-adp
spec:
  groups:
  - name: sample-oadp-backup-alert
    rules:
    - alert: OADPBackupFailing
      annotations:
        description: 'OADP had {{$value | humanize}} backup failures over the last 2 hours.'
        summary: OADP has issues creating backups
      expr: |
        increase(velero_backup_failure_total{job="openshift-adp-velero-metrics-svc"}[2h]) > 0
      for: 5m
      labels:
        severity: warning

在此示例中，警报在以下条件下显示

过去两小时内新增失败备份的数量大于 0，并且此状态持续至少 5 分钟。
如果第一次增加的时间少于 5 分钟，则警报将处于待定状态，之后将变为触发状态。

应用4_create_oadp_alert_rule.yaml 文件，这将在openshift-adp 命名空间中创建PrometheusRule 对象
```
$ oc apply -f 4_create_oadp_alert_rule.yaml
```
示例输出
```
prometheusrule.monitoring.coreos.com/sample-oadp-alert created
```

验证

警报触发后，您可以通过以下方式查看它
- 在**开发人员**视角中，选择**观察**菜单。
- 在**管理员**视角下的**观察** → **警报**菜单中，选择**用户**作为**过滤器**框中的选项。否则，默认情况下只会显示**平台**警报。
  
  图 2. OADP 备份失败警报

其他资源

管理警报

可用指标列表

以下是 OADP 提供的指标列表及其类型。

指标名称描述类型

指标名称	描述	类型
`kopia_content_cache_hit_bytes`	从缓存中检索到的字节数	计数器
`kopia_content_cache_hit_count`	从缓存中检索内容的次数	计数器
`kopia_content_cache_malformed`	从缓存中读取格式错误内容的次数	计数器
`kopia_content_cache_miss_count`	缓存中找不到内容并进行提取的次数	计数器
`kopia_content_cache_missed_bytes`	从底层存储检索到的字节数	计数器
`kopia_content_cache_miss_error_count`	底层存储中找不到内容的次数	计数器
`kopia_content_cache_store_error_count`	无法将内容保存到缓存中的次数	计数器
`kopia_content_get_bytes`	使用`GetContent()`检索到的字节数	计数器
`kopia_content_get_count`	调用`GetContent()`的次数	计数器
`kopia_content_get_error_count`	调用`GetContent()`并导致错误的次数	计数器
`kopia_content_get_not_found_count`	调用`GetContent()`并导致未找到结果的次数	计数器
`kopia_content_write_bytes`	传递给`WriteContent()`的字节数	计数器
`kopia_content_write_count`	调用`WriteContent()`的次数	计数器
`velero_backup_attempt_total`	尝试备份的总数	计数器
`velero_backup_deletion_attempt_total`	尝试删除备份的总数	计数器
`velero_backup_deletion_failure_total`	备份删除失败的总数	计数器
`velero_backup_deletion_success_total`	备份删除成功的总数	计数器
`velero_backup_duration_seconds`	完成备份所需的时间（秒）	直方图
`velero_backup_failure_total`	备份失败的总数	计数器
`velero_backup_items_errors`	备份期间遇到的错误总数	量规
`velero_backup_items_total`	已备份的项目总数	量规
`velero_backup_last_status`	备份的最后状态。值为 1 表示成功，0 表示失败。	量规
`velero_backup_last_successful_timestamp`	上次成功运行备份的时间（Unix 时间戳，单位为秒）	量规
`velero_backup_partial_failure_total`	部分备份失败总数	计数器
`velero_backup_success_total`	备份成功总数	计数器
`velero_backup_tarball_size_bytes`	备份大小（字节）	量规
`velero_backup_total`	当前存在的备份数量	量规
`velero_backup_validation_failure_total`	验证失败的备份总数	计数器
`velero_backup_warning_total`	备份警告总数	计数器
`velero_csi_snapshot_attempt_total`	尝试的CSI卷快照总数	计数器
`velero_csi_snapshot_failure_total`	CSI卷快照失败总数	计数器
`velero_csi_snapshot_success_total`	CSI卷快照成功总数	计数器
`velero_restore_attempt_total`	尝试恢复的总数	计数器
`velero_restore_failed_total`	恢复失败总数	计数器
`velero_restore_partial_failure_total`	部分恢复失败总数	计数器
`velero_restore_success_total`	恢复成功总数	计数器
`velero_restore_total`	当前存在的恢复数量	量规
`velero_restore_validation_failed_total`	验证失败的恢复总数	计数器
`velero_volume_snapshot_attempt_total`	尝试的卷快照总数	计数器
`velero_volume_snapshot_failure_total`	卷快照失败总数	计数器
`velero_volume_snapshot_success_total`	卷快照成功总数	计数器

kopia_content_cache_hit_bytes

从缓存中检索到的字节数

计数器

kopia_content_cache_hit_count

从缓存中检索内容的次数

计数器

kopia_content_cache_malformed

从缓存中读取格式错误内容的次数

计数器

kopia_content_cache_miss_count

缓存中找不到内容并进行提取的次数

计数器

kopia_content_cache_missed_bytes

从底层存储检索到的字节数

计数器

kopia_content_cache_miss_error_count

底层存储中找不到内容的次数

计数器

kopia_content_cache_store_error_count

无法将内容保存到缓存中的次数

计数器

kopia_content_get_bytes

使用GetContent()检索到的字节数

计数器

kopia_content_get_count

调用GetContent()的次数

计数器

kopia_content_get_error_count

调用GetContent()并导致错误的次数

计数器

kopia_content_get_not_found_count

调用GetContent()并导致未找到结果的次数

计数器

kopia_content_write_bytes

传递给WriteContent()的字节数

计数器

kopia_content_write_count

调用WriteContent()的次数

计数器

velero_backup_attempt_total

尝试备份的总数

计数器

velero_backup_deletion_attempt_total

尝试删除备份的总数

计数器

velero_backup_deletion_failure_total

备份删除失败的总数

计数器

velero_backup_deletion_success_total

备份删除成功的总数

计数器

velero_backup_duration_seconds

完成备份所需的时间（秒）

直方图

velero_backup_failure_total

备份失败的总数

计数器

velero_backup_items_errors

备份期间遇到的错误总数

量规

velero_backup_items_total

已备份的项目总数

量规

velero_backup_last_status

备份的最后状态。值为 1 表示成功，0 表示失败。

量规

velero_backup_last_successful_timestamp

上次成功运行备份的时间（Unix 时间戳，单位为秒）

量规

velero_backup_partial_failure_total

部分备份失败总数

计数器

velero_backup_success_total

备份成功总数

计数器

velero_backup_tarball_size_bytes

备份大小（字节）

量规

velero_backup_total

当前存在的备份数量

量规

velero_backup_validation_failure_total

验证失败的备份总数

计数器

velero_backup_warning_total

备份警告总数

计数器

velero_csi_snapshot_attempt_total

尝试的CSI卷快照总数

计数器

velero_csi_snapshot_failure_total

CSI卷快照失败总数

计数器

velero_csi_snapshot_success_total

CSI卷快照成功总数

计数器

velero_restore_attempt_total

尝试恢复的总数

计数器

velero_restore_failed_total

恢复失败总数

计数器

velero_restore_partial_failure_total

部分恢复失败总数

计数器

velero_restore_success_total

恢复成功总数

计数器

velero_restore_total

当前存在的恢复数量

量规

velero_restore_validation_failed_total

验证失败的恢复总数

计数器

velero_volume_snapshot_attempt_total

尝试的卷快照总数

计数器

velero_volume_snapshot_failure_total

卷快照失败总数

计数器

velero_volume_snapshot_success_total

卷快照成功总数

计数器

使用Observe UI查看指标

您可以在OpenShift Container Platform Web控制台中，以管理员或开发者视角查看指标，但必须具有访问openshift-adp项目的权限。

步骤

导航到监控 → 指标页面
- 如果您使用的是开发者视角，请按照以下步骤操作
  1. 选择自定义查询，或点击显示PromQL链接。
  2. 输入查询并点击回车。
- 如果您使用的是管理员视角，请在文本字段中输入表达式，然后选择运行查询。
  
  图3. OADP指标查询