业务连续性

集群备份和恢复 Operator 解决方案为所有 hub 集群资源（如受管集群、应用程序和策略）提供备份和恢复支持。您可以使用解决方案备份任何扩展基本 hub 集群安装的第三方资源。使用这个备份解决方案，您可以定义一个基于 cron 的备份调度，该调度在指定时间段内运行，并持续备份 hub 集群内容的最新版本。

当 hub 集群需要替换或处于灾难情况下，当 hub 集群停机时，可以部署新的 hub 集群并备份数据被移到新的 hub 集群中。

查看以下集群备份和恢复过程列表，以及它们如何备份或排除资源和组来识别备份数据：

您可以使用 Red Hat Advanced Cluster Management 调度来备份 hub 集群资源，这些资源根据资源类型或标签注解在单独的备份文件中分组。

BackupSchedule.cluster.open-cluster-management.io 资源会创建一组四个 schedule.velero.io 资源。这些 schedule.velero.io 资源生成备份文件，这些文件也称为资源。

要查看调度的备份文件列表，请运行以下命令： oc get schedule -A | grep acm。

调度的备份文件是 backup.velero.io。下表列出了这些调度的备份文件的描述：

将 cluster.open-cluster-management.io/backup 标签添加到资源时，资源会在 acm-resources-generic-schedule 备份中自动备份，但备份 acm-credentials-schedule-schedule- 中备份的 Secrets 和 ConfigMap 资源除外。如果您需要在将受管集群移至新的 hub 集群后恢复任何资源，并在恢复的资源中使用 veleroManagedClustersBackupName:latest，请将标签值设置为 cluster-activation。

当您将 cluster.open-cluster-management.io/backup 标签设置为 cluster-activation 时，您可以确保资源不会被恢复，除非激活受管集群。查看以下示例：

apiVersion: my.group/v1alpha1
kind: MyResource
 metadata:
  labels:
    cluster.open-cluster-management.io/backup: cluster-activation

注： 对于任何受管集群命名空间或其中的任何资源，您必须在集群激活步骤中恢复一个。因此，如果您需要添加到受管集群命名空间中创建的备份资源，请为 cluster.open-cluster-management.io/backup 标签使用 cluster-activation 值。要了解恢复过程，请查看以下信息：

除了使用 cluster.open-cluster-management.io/backup: cluster-activation 标签并由 acm-resources-generic-schedule 备份存储的激活数据资源外，集群备份和恢复 Operator 还默认在激活集合中包括一些资源。以下资源由 acm-managed-clusters-schedule 备份备份：

您可以通过在资源中添加 cluster.open-cluster-management.io/backup 标签来备份集群备份和恢复的第三方资源。标签的值可以是任意字符串，包括空字符串。使用一个可以帮助您识别要备份的组件的值。例如，如果组件是由 IDP 解决方案提供，请使用 cluster.open-cluster-management.io/backup: idp 标签。

注： 如果您希望在受管集群激活资源时恢复资源，请使用 cluster.open-cluster-management.io/backup 标签的 cluster-activation 值。当您恢复受管集群激活资源时，对由 hub 集群主动管理的受管集群开始恢复。

在主动-被动配置中，有一个主动 hub 集群和被动 hub 集群。一个活跃 hub 集群也被视为主 hub 集群，它使用 BackupSchedule.cluster.open-cluster-management.io 资源以定义的时间间隔管理集群并备份资源。

注： 要备份主 hub 集群数据，您不需要 主动 - 被动配置。您只需备份并存储 hub 集群数据。这样，如果出现问题或失败，您可以部署新的 hub 集群，并在这个新 hub 集群上恢复主 hub 集群数据。要减少恢复主 hub 集群数据的时间，您可以使用 主动 - 被动配置，但这不是必需的。

被动 hub 集群会持续检索最新的备份并恢复被动数据。当有新的备份数据时，被动 hub 使用 Restore.cluster.open-cluster-management.io 资源从主 hub 集群恢复被动数据。这些 hub 集群处于备用状态，当主 hub 集群失败时会成为主 hub 集群。

主动和被动 hub 集群连接到相同的存储位置，主 hub 集群备份 被动 hub 集群的数据，以访问主 hub 集群。有关如何设置此自动恢复配置的详情，请参阅在检查备份时恢复被动资源。

在以下图中，活跃 hub 集群会管理本地集群并定期备份 hub 集群数据：

被动 hub 集群恢复这个数据，但受管集群激活数据除外，后者将受管集群移到 passive hub 集群。被动 hub 集群可以持续恢复被动数据。被动 hub 集群可以将被动数据恢复为一次性操作。如需了解更多详细信息，请参阅恢复被动资源。

当主 hub 集群失败时，作为 hub 管理员，您可以选择一个被动 hub 集群来接管受管集群。在以下 灾难恢复图中，请参阅 如何使用 Hub 集群 N 作为新的主 hub 集群：

hub 集群 N 恢复受管集群激活数据。受管集群连接到 Hub 集群 N。您可以通过创建一个 BackupSchedule.cluster.open- cluster -management.io 资源，并将备份存储在与初始主 hub 集群相同的存储位置，在新的主 hub 集群上激活备份。

所有其他被动 hub 集群现在使用新的主 hub 集群创建的备份数据恢复被动数据。Hub N 现在是主 hub 集群，管理集群和备份数据。

重要：

有关被动资源的更多信息，请参阅以下恢复选项：

要使用备份和恢复 Operator，您必须设置 hub 集群。要设置 hub 集群，请按顺序完成以下部分：

当第一次创建 MultiClusterHub 资源时，可以启用集群备份和恢复 Operator。cluster-backup 参数设为 true。启用 Operator 后，会安装 operator 资源。

如果已创建了 MultiClusterHub 资源，您可以通过编辑 MultiClusterHub 资源来安装或卸载集群备份 Operator。如果要卸载集群备份 Operator，将 cluster-backup 设置为 false。

启用备份和恢复 Operator 时，MultiClusterHub 资源可能类似以下 YAML 文件：

apiVersion: operator.open-cluster-management.io/v1
  kind: MultiClusterHub
  metadata:
    name: multiclusterhub
    namespace: open-cluster-management
  spec:
    availabilityConfig: High
    enableClusterBackup: false
    imagePullSecret: multiclusterhub-operator-pull-secret
    ingress:
      sslCiphers:
        - ECDHE-ECDSA-AES256-GCM-SHA384
        - ECDHE-RSA-AES256-GCM-SHA384
        - ECDHE-ECDSA-AES128-GCM-SHA256
        - ECDHE-RSA-AES128-GCM-SHA256
    overrides:
      components:
        - enabled: true
          name: multiclusterhub-repo
        - enabled: true
          name: search
        - enabled: true
          name: management-ingress
        - enabled: true
          name: console
        - enabled: true
          name: insights
        - enabled: true
          name: grc
        - enabled: true
          name: cluster-lifecycle
        - enabled: true
          name: volsync
        - enabled: true
          name: multicluster-engine
        - enabled: true
          name: cluster-backup
    separateCertificateManagement: false

如果 hub 集群的状态从被动改为主 hub 集群，或从主到被动（从主到被动）和不同的 hub 集群备份同一存储位置的数据，则可能会出现备份冲突。

因此，最新的备份由 hub 集群生成，该集群不再设置为主 hub 集群。这个 hub 集群仍然会生成备份，因为 BackupSchedule.cluster.open-cluster-management.io 资源仍被启用。

当您在受控环境中运行恢复操作（如灾难恢复测试操作）时，您可以在使用备份 hub 集群上的 BackupSchedule 暂停 属性时防止备份冲突。在恢复新 hub 集群上的资源前，请通过在 BackupSchedule 资源上设置 paused=true 属性来暂停备份 hub 上的 BackupSchedule 资源。

请参阅以下列表以了解两个可能会导致备份冲突的情况：

要防止和报告备份冲突，请使用 BackupSchedule.cluster.open-cluster-management.io 资源中的 BackupCollision 状态。控制器定期检查存储位置的最新备份是否已从当前 hub 集群生成。如果没有，则不同的 hub 集群最近已将备份数据写入存储位置，这表示 hub 集群与不同的 hub 集群合并。

在备份冲突场景中，当前 hub 集群 BackupSchedule.cluster.open-cluster-management.io 资源状态被设置为 BackupCollision。要防止数据崩溃，此资源会删除 Schedule.velero.io 资源。备份策略报告 BackupCollision。

在同一场景中，管理员会验证哪些 hub 集群写入存储位置。管理员在从无效的 hub 集群中删除 BackupSchedule.cluster.open-cluster-management.io 资源前进行这个验证。然后，管理员可以在有效的主 hub 集群上创建一个新的 BackupSchedule.cluster.open-cluster-management.io 资源，恢复备份。

要检查是否有备份冲突，请运行以下命令：

oc get backupschedule -A

如果存在备份冲突，输出可能类似以下示例：

NAMESPACE       NAME               PHASE             MESSAGE
openshift-adp   schedule-hub-1   BackupCollision   Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to  resume backups from this cluster.

使用恢复操作恢复备份操作创建的所有 3 个备份类型。您可以选择只安装特定类型的备份，如只安装受管集群、只有用户凭证或只安装 hub 集群资源。

恢复定义以下三个必要的 spec 属性，其中为备份文件类型定义了恢复逻辑：

由 restore.cluster.open-cluster-management.io 创建的 restore.velero.io 资源的名称遵循以下模版规则 <restore.cluster.open-cluster-management.io name>-<velero-backup-resource-name>.查看以下描述：

注：如果 skip 用于备份类型，则不会创建 restore.velero.io。

查看以下集群 Restore 资源的 YAML 示例。在这个示例中，使用最新可用的备份文件恢复所有三种备份文件：

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

Note:当来自受管集群备份的 acm-managed-clusters 备份被恢复到另外一个 hub 集群时，只有 Hive API 创建的受管集群会自动连接到新的 hub 集群。所有其他受管集群都处于 Pending Import 状态，且必须重新导入到新的 hub 集群中。如需更多信息，请参阅恢复导入的受管集群。

当您需要恢复集群中的备份数据时，请创建一个新集群，而不是使用主 hub 集群，或使用在恢复操作前创建用户资源的 hub 集群。在 hub 集群恢复操作中，您可以将 hub 集群备份恢复配置为清理现有资源，如果这些资源不是正在恢复的备份数据的一部分。恢复会清理之前备份创建的资源，但不会清理用户资源。因此，在此 hub 集群上用户创建的资源不会被清理，因此此 hub 集群上的数据不会反映恢复的资源可用的数据。

灾难恢复测试，如果您只验证被动 hub 上的恢复操作，然后重新使用主 hub 集群，您可以使用主 hub 集群作为被动集群。在这个恢复测试场景中，您只测试 hub 备份场景。不要使用主 hub 集群创建新资源。相反，备份数据已从主 hub 集群临时移到 passive hub 集群。如果您将所有资源恢复到此 hub 集群，您可以使初始主 hub 集群再次成为主 hub 集群。此操作运行后恢复操作，它将受管集群移到此 hub 集群。

当您需要在 hub 集群上恢复备份数据时，请创建一个新的 hub 集群，而不是使用主 hub 集群，或之前在恢复操作前创建资源的 hub 集群。

在灾难恢复场景中，当将备份恢复到被动 hub 集群时，您希望一个 hub 集群与灾难过程中失败的 hub 集群相同。您不需要任何其他用户资源，如应用程序、策略和额外的受管集群。

当您恢复此 hub 集群上的备份时，如果您有由此 hub 集群管理的受管集群，恢复操作可能会分离它们并删除其集群资源。恢复操作会进行清理不是恢复备份一部分的资源，使此 hub 集群中的内容与初始 hub 集群相同。在这种情况下，您可能会丢失用户数据，因为受管集群工作负载由 detach 操作删除。

在新 hub 集群上运行恢复操作前，您需要手动配置 hub 集群，并在初始 hub 集群上安装相同的 Operator。您必须在与初始 hub 集群相同的命名空间中安装 Red Hat Advanced Cluster Management Operator，创建 DataProtectionApplication 资源，然后连接到之前备份了数据的同一存储位置。

对 Red Hat Advanced Cluster Management Operator 创建的 MultiClusterHub 资源使用与初始 hub 集群上的配置相同，包括对 MultiClusterEngine 资源的任何更改。

例如，如果初始 hub 集群安装了任何其他 Operator，如 Ansible Automation Platform、Red Hat OpenShift GitOps、cert-manager，则必须在运行恢复操作前安装它们。这样可确保配置新的 hub 集群与初始 hub 集群相同。

如果使用当前恢复的备份更改了，Velero 会更新现有资源。Velero 不会清理 delta 资源，这些资源是由以前的恢复创建的资源，而不是当前恢复的备份的一部分。这限制了在新 hub 集群上恢复 hub 集群数据时可以使用的情况。除非恢复只应用一次，否则您无法可靠地使用新的 hub 集群作为被动配置。hub 集群中的数据没有反映恢复的资源可用的数据。

为解决这个限制，当创建 Restore.cluster.open-cluster-management.io 资源时，备份 Operator 会运行一个清理 hub 集群的 post 恢复操作。该操作会删除之前不是由 Red Hat Advanced Cluster Management 恢复（不是当前恢复的备份的一部分）创建的资源。

后恢复清理使用 cleanupBeforeRestore 属性来识别要清理的对象子集。您可以使用以下选项进行后恢复清理：

备注：

使用 restore-passive-sync 示例恢复被动数据，同时继续检查新备份是否可用并自动恢复它们。要自动恢复新的备份，您必须将 syncRestoreWithNewBackups 参数设置为 true。您还必须仅恢复最新的被动数据。您可以在本节末尾找到示例示例。

将 VeleroResourcesBackupName 和 VeleroCredentialsBackupName 参数设置为 latest，VeleroManagedClustersBackupName 参数为 skip。当将 VeleroManagedClustersBackupName 设置为 latest 后，受管集群会在新的 hub 集群中激活，现在是主 hub 集群。

当激活的受管集群变为主 hub 集群时，恢复资源被设置为 Finished，并且 syncRestoreWithNewBackups 会被忽略，即使设置为 true。

默认情况下，当 syncRestoreWithNewBackups 设为 true 时，控制器会每 30 分钟检查新的备份。如果找到新的备份，它会恢复备份的资源。您可以通过更新 restoreSyncInterval 参数来更改检查的持续时间。

如果要在恢复操作完成后再次运行相同的恢复操作，您必须创建一个具有相同 spec 选项的新 restore.cluster.open-cluster-management.io 资源。

例如，请查看以下资源每 10 分钟检查备份：

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-sync
  namespace: open-cluster-management-backup
spec:
  syncRestoreWithNewBackups: true # restore again when new backups are available
  restoreSyncInterval: 10m # check for new backups every 10 minutes
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

使用 restore-acm-passive 示例在被动配置中恢复 hub 集群资源。被动数据是备份数据，如 secret、ConfigMap、应用程序、策略以及所有受管集群自定义资源，它不在受管集群和 hub 集群之间激活连接。备份资源通过凭证备份和恢复资源在 hub 集群上恢复。

请参见以下示例：

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

在恢复被动 hub 集群上的激活数据前，请关闭创建备份的之前的 hub 集群。如果主 hub 集群仍在运行，它会尝试根据在此 hub 集群上运行的协调流程，尝试使用不再可用的受管集群。

当您希望 hub 集群管理集群时，请使用 restore-acm-passive-activate 示例。在这种情况下，假设其它数据已在使用被动资源的 hub 集群上恢复。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-activate
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: skip
  veleroResourcesBackupName: skip

根据您如何恢复被动资源，您有一些选项来恢复激活资源：

当使用 cluster.open-cluster-management.io/backup: cluster-activation 标签时，受管集群激活数据或其他激活数据资源由受管集群备份和 resource-generic 备份存储。当在新的 hub 集群上恢复激活数据时，受管集群由运行恢复的 hub 集群主动管理。请参阅 调度和恢复备份 以了解如何使用 Operator。

要恢复所有数据，请使用以下 restore-acm 示例：

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

在 hub 集群中创建 restore.cluster.open-cluster-management.io 资源后，运行以下命令来获取恢复操作的状态：

oc describe -n open-cluster-management-backup restore-acm

只有使用 Hive API 与主 hub 集群连接的受管集群会自动连接到新的 hub 集群，其中恢复激活数据。这些集群由 Hive API 在主 hub 集群上创建，使用 Clusters 选项卡中的 Create cluster 按钮或通过 CLI 创建。当激活数据被恢复时，使用 Import cluster 按钮连接到初始 hub 集群的受管集群显示为 Pending Import，需要在新的 hub 集群中重新导入。

Hive 受管集群可以与新的 hub 集群连接，因为 Hive 将受管集群 kubeconfig 存储在 hub 集群上的受管集群命名空间中。这在新的 hub 集群上备份和恢复。然后，导入控制器使用恢复的配置更新受管集群上的 bootstrap kubeconfig，该配置仅适用于使用 Hive API 创建的受管集群。导入的集群不可用。

要在恢复操作过程中重新在新 hub 集群上重新连接导入的集群，请在 BackupSchedule 上启用自动导入功能。如需更多信息，请参阅启用自动导入。

查看以下 YAML 示例以恢复不同类型的备份文件：

使用以下命令获取有关恢复事件的信息：

oc describe -n open-cluster-management-backup <restore-name>

您的事件列表可能类似以下示例：

Spec:
  Cleanup Before Restore:               CleanupRestored
  Restore Sync Interval:                4m
  Sync Restore With New Backups:        true
  Velero Credentials Backup Name:       latest
  Velero Managed Clusters Backup Name:  skip
  Velero Resources Backup Name:         latest
Status:
  Last Message:                     Velero restores have run to completion, restore will continue to sync with new backups
  Phase:                            Enabled
  Velero Credentials Restore Name:  example-acm-credentials-schedule-20220406171919
  Velero Resources Restore Name:    example-acm-resources-schedule-20220406171920
Events:
  Type    Reason                   Age   From                Message
  ----    ------                   ----  ----                -------
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-generic-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-cluster-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      64m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-cluster-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406171920
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406171920
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-cluster-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-generic-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-hive-schedule-20220406171919

默认情况下，禁用使用 Managed Service Account 组件的自动导入功能。要启用自动导入功能，请完成以下步骤：

启用自动导入功能后，备份组件通过创建以下内容开始处理导入的受管集群：

只有在创建 Managed Service Account 时可以访问受管集群时，才会创建令牌，否则在受管集群可用后它会被创建。

以下场景可能会阻止受管集群在迁移到新 hub 集群时被自动导入：

您可以通过在 BackupSchedule 资源中将 useManagedServiceAccount 参数设置为 false 来禁用自动导入集群功能。请参见以下示例：

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule:
  veleroTtl: 120h
  useManagedServiceAccount: false

默认值为 false。将值设为 false 后，备份 Operator 会删除所有创建的资源，包括 ManagedServiceAddon、ManagedServiceAccount 和 ManifestWork。删除资源会删除 hub 集群和受管集群中的自动导入令牌。

服务器端加密是应用程序或服务的数据加密，在存储位置接收数据。在传输过程中，备份机制本身不会加密数据（因为它会前往备份存储位置），或其他人（同时存储在备份存储位置的磁盘上）。它依赖于对象和快照系统中的原生机制。

最佳实践 ：使用可用的备份存储服务器端加密数据。备份包含资源，如在 hub 集群外存储需要加密的凭证和配置文件。

您可以使用 serverSideEncryption 和 kmsKeyId 参数为存储在 Amazon S3 中的备份启用加密。如需了解更多详细信息，请参阅备份存储位置 YAML。以下示例指定在设置 DataProtectionApplication 资源时的 AWS KMS 密钥 ID：

spec:
  backupLocations:
    - velero:
        config:
          kmsKeyId: 502b409c-4da1-419f-a16e-eif453b3i49f
          profile: default
          region: us-east-1

请参阅 Velero 支持的存储供应商，以找出其它存储供应商的所有可配置参数。

在运行恢复操作并保持 hub 集群活跃前，您必须准备主 hub 集群。

要准备主 hub 集群，请完成以下步骤：

准备主 hub 集群后，在新 hub 集群上运行恢复操作并移动受管集群。受管集群连接到新的 hub 集群，且不会返回到初始 hub 集群，因为备份 hub 集群上现在禁用了自动导入功能。

通过完成以下步骤，在新的 hub 集群中运行恢复操作：

在恢复并成功连接到新的 hub 集群后，从初始备份 hub 集群中清理受管集群资源。如果要在恢复测试完成后将数据恢复到备份，请跳过清理资源

要从备份 hub 集群清理受管集群，请完成以下步骤：

重要：

最初安装 Velero 时，Velero pod 会被设置为默认 CPU 和内存限值，如下例所示：

resources:
 limits:
   cpu: "1"
   memory: 256Mi
 requests:
   cpu: 500m
   memory: 128Mi

以上示例中的限制在某些情况下可以正常工作，但可能会在集群备份大量资源时进行更新。例如，当备份在管理 2000 集群的 hub 集群上运行时，Velero pod 会因为内存不足错误(OOM)崩溃。对于这种情况，以下配置允许备份完成：

  limits:
    cpu: "2"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

要更新 Velero pod 资源的限制和请求，您需要更新 DataProtectionApplication 资源，并为 Velero pod 插入 resourceAllocation 模板。查看以下示例：

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero
  namespace: open-cluster-management-backup
spec:
...
  configuration:
...
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "2"
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 256Mi

如果您计划用于恢复操作的 hub 集群已管理集群，并且运行 restore 操作，并将 cleanupBeforeRestore d 设置为 CleanupRestored，则预期以下结果：

当使用较早用户创建的数据恢复 hub 集群时，对于恢复操作将 cleanupBeforeRestore d 设置为 CleanupRestored，则恢复 hub 集群的资源与主 hub 集群的资源不匹配。用户数据包括以下资源： 策略、应用程序、凭证 或用户定义的任何自定义资源。不会清理资源，因为资源由用户创建，而不是由早期备份创建。

如果要将现有 hub 集群用于恢复 hub 集群配置，并期望 hub 集群在恢复完成后与备份 hub 集群具有相同的内容，请标记您要成为 hub 集群备份的任何资源。如需更多信息，请参阅 标记资源。

要使用 velero.io/backup-name: backupName 标签在恢复 hub 集群上标记用户创建的资源，请完成以下步骤：

Operator 会通过作为 hub 集群备份一部分的每个资源，并使用 velero.io/backup-name: backupName 标记，其中 backupName 是最新备份的名称。

标记资源后，您可以使用 hub 集群作为恢复集群。现在，您可以通过更新 DataProtectionApplication 存储位置来指向备份 hub 集群的存储位置，以便您可以运行使用 hub 集群备份资源的恢复操作，从主 hub 集群恢复数据。

所有恢复 hub 集群资源都使用 velero.io/backup-name 标签标记，因此 hub 集群会显示早期恢复生成的。因此，在使用 cleanupBeforeRestore 选项设置为 CleanupRestored 时，您在现有 hub 集群上运行的恢复操作都会清理不是恢复的备份一部分的数据。

重要：

要为恢复操作准备备份 hub 集群并运行恢复，请完成以下文档： 在恢复过程中保持主 hub 集群处于活动状态。

要开始模拟，您必须通过完成以下步骤使新的 hub 集群设置为活跃 hub 集群：

在灾难恢复测试完成后，您可以返回到主 hub 集群，并使其成为管理集群机的活跃 hub 集群。要做到这一点，请完成以下部分以返回到主集群：

在集群上安装 VolSync 前，您必须满足以下要求：

要启用 VolSync 将一个集群上的持久性卷声明复制到另一个集群的持久性卷声明，您必须在源和目标受管集群中安装 VolSync。

VolSync 不创建自己的命名空间，因此它与其他 OpenShift Container Platform all-namespace operator 相同的命名空间中。对 VolSync 的 Operator 设置所做的任何更改也会影响同一命名空间中的其他 Operator，例如，如果您更改为手动批准频道更新。

您可以使用两种方式之一在环境中的两个集群中安装 VolSync。您可以为 hub 集群中的每个受管集群添加标签，也可以手动创建并应用 ManagedClusterAddOn，如以下部分所述：

您可以使用 Rsync-TLS 复制创建持久性卷的 1:1 异步复制。您可以使用基于 Rsync-TLS 的复制进行灾难恢复，或者将数据发送到远程站点。使用 Rsync-TLS 时，Volis 在 stunnel 提供的 TLS 保护隧道中使用 Rsync 来同步数据。如需更多信息，请参阅 stunnel 文档。

以下示例演示了如何使用 Rsync-TLS 方法配置。有关 Rsync-TLS 的更多信息，请参阅 VolSync 文档中的使用情况。

重要：使用 Rsync-TLS 而不是 Rsync 来提高安全性。通过使用 Rsync-TLS，您可以避免使用复制持久性卷不需要的提升用户权限。

您可以使用 Rsync 复制创建持久性卷的 1:1 异步复制。您可以使用基于 Rsync 的复制进行灾难恢复，或者将数据发送到远程站点。

以下示例演示了如何使用 Rsync 方法配置。

基于 restic 的备份将持久性卷的 restic 备份副本复制到在 restic-config.yaml secret 文件中指定的位置。剩余的备份不会在集群之间同步数据，而是提供数据备份。

完成以下步骤以配置基于剩余的备份：

注：默认情况下，Restic movers 在没有 root 权限的情况下运行。如果要以 root 用户身份运行 restic movers，请运行以下命令将升级的权限注解添加到您的命名空间。

oc annotate namespace <namespace> volsync.backube/privileged-movers=true

将 <namespace> 替换为您的命名空间的名称。

Rclone 备份通过中间对象存储位置（如 AWS S3）使用 Rclone 将单个持久性卷复制到多个位置。将数据分发到多个位置时非常有用。

完成以下步骤以配置 Rclone 复制：

注：默认情况下，Rclone movers 运行没有 root 权限。如果要以 root 用户身份运行 Rclone movers，请运行以下命令将升级的权限注解添加到您的命名空间。

oc annotate namespace <namespace> volsync.backube/privileged-movers=true

将 <namespace> 替换为您的命名空间的名称。

如需更多信息，请参阅以下内容：

源和目标必须具有对 TLS 连接的共享密钥的访问权限。您可以在 keySecret 字段中找到密钥位置。如果您没有在 .spec.rsyncTLS.keySecret 中提供 secret 名称，secret 名称会被自动生成并添加到 .status.rsyncTLS.keySecret 中。

要创建自己的 secret，请完成以下步骤：