无论何时您对自己的内容进行更改 MAS 系统，你需要一个可靠的应急计划。如果出现问题，你将如何恢复？

这里的目标是尽可能降低风险，避免让环境处于不良状态。

MAS 备份的两种方法

IBM 提供了两种主要方法：
‍

‍

第一个是GitHub脚本，它已经存在了几年。

第二个选项是更新的：2026 年 3 月刚刚发布的两个 Ansible 角色。

让我们看看两者，看看它们是如何比较的。

方法 1：Github 脚本

专用的备份脚本可用于核心 (mascore-backup-restore.sh) 和管理 (manage-backup-restore.sh)。这些脚本可用于 GitHub 并且还直接捆绑在 MAS CLI 中，使其易于访问和运行。
‍

在 MAS CLI 的 mascli/backup-restore 中找到 MAS Core 和 Manage 备份脚本。
‍

‍

需要集群访问权限

这些脚本直接与 MAS 命名空间和资源交互，需要管理员访问 OpenShift 集群。

收集参数

命名空间包含执行这些脚本所需的大部分参数。
‍

‍

执行 MAS 核心备份

要运行 mascore-backup-restore.sh，请提供脚本位置、实例 ID、要将文件备份到的位置和模式。
‍

‍
检查所有备份文件以验证所有资源是否已成功备份。

执行管理备份

使用相同的参数执行 manage-backup-restore.sh，包括工作空间 ID。
‍

‍

方法 2：Ansible 角色

新的 MAS CLI 备份和恢复命令

从 MAS 版本 36.0.0 开始，MAS CLI 包括与 OpenShift Pipelines 集成的增强型备份和恢复命令。
‍

‍

在我们深入执行之前 批量备份 命令，了解可用的选项很重要。
‍

有 32 种不同的 参数，但它们实际上可以分为六个关键领域：

• 我们在备份什么实例？

• 我们要如何配置备份？

• 备份将存储在哪里？

• 包括哪些应用程序？

• 正在备份哪些组件？

• 备份中是否涉及任何潜在的依赖关系或高级选项？
  ‍

‍

在 MAS CLI 中执行批量备份

下面的 MAS 备份命令包括管理应用程序，该应用程序仍需要指定工作空间 ID。它还包括 SLS 并指定安装它的命名空间。
‍

我最初几次运行这个命令时，它在备份前检查任务中几乎立即失败了。
‍

备份前检查可验证 OpenShift 集群中每个组件的运行状况，当你只是尝试运行有针对性的备份时，这并不理想。使用--ski-pre-check 参数来绕过它。
‍

‍

启动备份后，幕后会发生一些事情。
‍

OpenShift Pipelines Operator 被安装到核心命名空间中，然后安装到管理命名空间中，因为它包含在备份中，它还会创建一个专用的命名空间 管道 操作员也安装的命名空间。
‍

因此，这不仅仅是备份，还是在对您的集群进行更改。
‍

‍

随着备份的进行并安装其依赖项，链接指向 PipeleRun 在 MAS CLI 窗口中提供。
‍

从那时起，你需要继续直接从 OpenShift 集群监控备份。
‍

Pipeline Run 为您提供了从验证到最终上传的整个备份过程的分步可视化视图，因此您可以实时监控进度。
‍

‍
MAS 备份的局限性

• 某些环境（例如 SNO、AWS、AWS、Azure）不支持某些存储类别和访问模式。

• 仅支持 MongoDB 社区版。

• 备份前检查会扫描整个集群，但可以跳过。

‍