概述

集群创建或接入成功后，我们建议您定期对集群数据进行备份。备份数据可以让您从意外灾难中快速恢复，也能帮您轻松地跨集群迁移业务数据，并保证数据的可靠性。

您可通过在平台上创建备份策略，配置要备份的数据类型（ETCD 中存储的集群配置数据、业务应用数据）、数据源（节点、命名空间）、存储位置、备份方式及规则等信息。之后，通过触发策略即可按照策略中的配置进行备份，方便您随时或周期性地自动备份集群数据。

相应地，当您需要恢复集群业务数据时，可通过执行应用恢复任务基于已有的备份文件进行恢复。

提示：如需基于 ETCD 备份数据恢复集群的配置，请联系技术支持人员。

使用场景

针对不同的备份恢复场景，我们建议您按照以下推荐的方式配置备份策略并进行恢复。

在当前 Kubernetes 集群应用和数据备份恢复

当本地应用出现故障（如命名空间被意外删除）时，可通过备份文件将应用恢复到当前集群。恢复过程中一般无需修改应用资源本身（如外部服务的域名和端口），仅需还原相应集群资源。

1. 部署插件：在当前业务集群下 部署备份恢复组件 ，并为其配置默认存储（对接 S3）。

2. 创建备份任务：在当前集群下 创建应用备份策略 ，选择备份运行业务应用的命名空间，并定时自动进行备份。

3. 执行恢复任务：需要恢复时，在当前集群下 执行应用恢复任务 。

跨集群业务数据迁移

跨集群数据备份恢复的普遍场景如下：

• 对于传统开发、测试的场景，应用需要跨机房迁移，数据将从备份文件将恢复至其它集群，恢复完成后可能需要进行应用资源相关的修改（如对外服务的域名和端口等）。

• 对于集群资源迁移到其他集群的数据迁移场景。

• 将生产集群资源复制到开发和测试集群的数据迁移场景。

前提条件

• 尽量保证待迁移集群和目标集群的 CPU、内存等规格配置相同或不要相差太大，以免出现迁移后的 Pod 因资源原因无法调度导致 Pending 的情况。

• 尽量保证待迁移集群和目标集群的网络模式保持一致，否则在恢复时可能会导致部分资源恢复异常，若子网不同，Pod IP 恢复后将会变动。

推荐方式

1. 部署插件：在 待迁移 和 目标 业务集群下 部署备份恢复组件 ，并为其配置默认存储（对接 S3）。

2. 创建备份任务：在 待迁移 集群下 创建应用备份策略 ，选择备份运行业务应用的命名空间，并定时自动进行备份。

3. 判断是否进行镜像迁移：在恢复数据前，请根据实际情况考虑是否进行 镜像迁移，一般的，若您的镜像仓库并未部署在源集群或目标集群中，可保证两个集群都可访问该镜像仓库，在该场景下，可不进行本步骤。对于下述场景，您需要进行镜像迁移操作，迁移操作请参考 镜像地址批量替换方案 。

4. 执行恢复任务：在 目标 集群下 执行应用恢复任务 。

5. 命名空间导入：数据迁移后，您需在 项目管理 中手动将命名空间导入至相应的项目中，参考 导入命名空间 ，否则可能导致恢复后的应用无法在平台前端界面上查看。

跨平台应用和数据迁移

若您有两套平台，例如容灾场景下，主平台集群故障需要切换至备平台的相应集群中，应用迁移后需要进行应用资源的修改（如对外服务的域名和端口等）。

前提条件

• 尽量保证待迁移集群和目标集群的 CPU、内存等规格配置相同或不要相差太大，以免出现迁移后的 Pod 因资源原因无法调度导致 Pending 的情况。

• 尽量保证待迁移集群和目标集群的网络模式保持一致，否则在恢复时可能会导致部分资源恢复异常，若子网不同，Pod IP 恢复后将会变动。

注意事项

数据迁移后，您需手动将命名空间导入至相应的项目中，否则可能导致恢复后的应用无法在平台前端界面上查看。

推荐方式

1. 部署插件：在 待迁移 平台和 目标 平台业务集群下 部署备份恢复组件 ，并为其配置默认存储（对接 S3）。

2. 创建备份任务：在 待迁移 集群下 创建应用备份策略 ，选择备份运行业务应用的命名空间，并定时自动进行备份。

3. 判断是否进行镜像迁移：在恢复数据前，请根据实际情况考虑是否进行 镜像迁移，一般的，若您的镜像仓库并未部署在源集群或目标集群中，可保证两个集群都可访问该镜像仓库，在该场景下，可不进行本步骤。对于下述场景，您需要进行镜像迁移操作，迁移操作请参考 镜像地址批量替换方案 。

4. 执行恢复任务：在 目标 集群下 执行应用恢复任务 。

5. 命名空间导入：数据迁移后，您需在 项目管理 中手动将命名空间导入至相应的项目中，参考 导入命名空间 ，否则可能导致恢复后的应用无法在平台前端界面上查看。