业务连续性和灾难恢复
在大规模管理云时，实现业务连续性和灾难恢复的整体策略至关重要。 此建议扩展了 IBM Cloud Framework for Financial Services 中的业务连续性建议，并提供了一些其他细节，用于扩展 IBM Cloud 常规灾难恢复策略。
IBM Cloud Framework for Financial Services中的关键点:
- 在地理上与备份的工作负载不同的区域中建立备份存储器
- 对系统复原操作所需的所有信息进行定期和频繁备份
- 监视备份和测试恢复过程，以确保在需要恢复时成功
- 保护存储位置的备份信息的机密性，完整性和可用性
- 制定应急计划，其中包括验证成功恢复和重建原始配置的过程
高可用性部署
对于 高可用性部署，基础结构和应用程序的其他副本应部署在同一工作负载帐户中，并由与主基础结构相同的项目进行部署。 这样可以更轻松地确保其他区域保持同步，并简化 DevOps 团队的配置访问。
基础架构即代码
基础架构作为代码应该用于创建任何其他部署以实现高可用性，无论是主动/主动，主动/备用还是主动/被动。 这有助于确保为高可用性而创建的其他区域与主区域保持同步，并提供使用基础结构作为代码的所有其他安全性，合规性和监管优势。
主动/被动
当使用主动/被动 (冷备用) 策略时，基础架构即代码支持应急计划，包括使用自动化来按需创建基础架构。 这允许非常便宜的主动/被动配置，因为不需要维护昂贵的基础架构。 由于此方法的成本较低，因此可以将主动/主动或主动/备用高可用性策略与主动/被动策略相结合，尤其是针对重要工作负载。
确保自动化代码 (例如， Terraform ，可部署体系结构和关联配置) 包含在备份的数据中，并使其高度可用。
主动/被动准备
在恢复速度和成本之间需要进行 权衡 。 由于设置物理网络连接是一个缓慢的过程，因此即使对于主动/被动 (冷备用) 配置，也应建立到至少一个备用区域的直接链路连接。
网络连接可用后，可针对每个 BU 或每个工作负载定制恢复策略。 在低成本，缓慢的频谱恢复端，替代区域中所有必需的基础架构都从基础架构重新创建为代码。 在另一端，使用正在运行的应用程序维护所有基础架构的副本，以实现近乎即时的恢复。 其中有维护引导程序基础结构的选项，例如，用于缩短恢复时间的传输网关和示意图代理程序。 在所有情况下，在基础结构可用后，将先从备份复原数据，然后再激活被动部署。
激活备用区域
如果发生区域中断，那么可以按照预先建立并测试的过程来激活备用区域。 这些过程可以包括使用预先创建和测试的项目配置在区域中部署基础结构，以便可以轻松完成无错误的部署。 如果未维护预先存在的项目，那么可以从备份复原项目配置并将其修改为以备用区域为目标。
平台服务 (例如，企业帐户，帐户， IAM 和目录) 是全局服务，因此不受区域中断影响。 在灾难恢复过程中，可以继续未更改地使用企业帐户层次结构，专用目录和所有 IAM 配置。 必须在新区域中恢复包括网络， VPC ，各种计算，存储和数据库的区域服务实例。
备份
备份必须存储在与工作负载不同的区域中，最好存储在单独的备份帐户中。 在位置和管理域 (帐户) 中进行此分隔可最大程度地降低影响工作负载的中断，操作错误或安全违规也会影响备份的可能性。 备份区域应该是多专区 IBM Cloud 区域或高可用性 Satellite 区域。 但是， IBM Cloud 上的每个服务系列都有自己的备份机制，这些机制引入了一些影响此整体策略的限制。 有关更多信息，请参阅 服务注意事项。
此外，应在 IBM Cloud外部开发和存储 "灾难恢复工具包"。 灾难恢复工具包是一个非现场且受保护的存储库，包含硬件，软件和系统安全配置，一次性密钥以及灾难恢复计划。 在事件响应期间使用此灾难恢复工具包来复原服务。
基础架构即代码
基础架构即代码可确保在整个组织中以统一的方式实施良好的备份实践。 将备份实现包括在可部署体系结构中。 使备份配置与供应代码保持接近，以便更容易确保随着信息系统更改而调整备份。 创建备份帐户并将其配置为代码。
备份帐户
每个 BU 帐户组都应该包含一个单独的备份帐户，并且应该为集中帐户使用一个额外的备份帐户。 这些备份帐户为备份数据的机密性和完整性提供额外的保护层。 如果源帐户的凭证受到攻击，那么不应该使用该访问权来篡改备份。
在支持此工作的情况下，在备份帐户中备份数据的授权应该使用服务到服务或服务到可信概要文件的授权 (如果可能)。 否则，请使用具有最少特权访问权的凭证的安全存储。
如果要使用 Cloud Object Storage 进行备份，请至少使用单独的存储区来备份不同的工作负载帐户。 此外，对于无法使用服务到服务策略的每个存储区，请使用单独的备份凭证。 使用 Cloud Object Storage 版本控制或 不可改变的存储区 以实现最大限度的安全性。
提供内置备份设施的服务在备份帐户方面可能存在限制。
特定于服务的注意事项
IBM Cloud Databases
IBM Cloud Databases 提供了存储在同一帐户和地理位置中的自动每日备份。 备份通常存储在 跨区域存储器 中，因此应避免单个区域中断。 此设施可靠且方便，但当前不支持在指定的备用区域或帐户中进行备份存储。 但是，备份可以 复原到其他区域或帐户，因此支持恢复到被动部署 (冷备用)。
还可以使用特定于数据库的客户机 (例如， pg_dump for PostgreSQL) 通过使用客户自动化将 IBM Cloud Databases 备份到任意存储器。 如果使用了这些备份，那么应将这些备份存储在 Cloud Object Storage 中的备用区域和备份帐户中，如 备份帐户中所述。
虚拟服务器
卷快照 和 Veeam 都可用于备份虚拟服务器。 Veeam 是广泛的功能集及其备份应用程序工作负载的能力的首选。 但是， Veeam 需要将代理程序部署到未在 VMWare 上托管的备份工作负载。 用于备份的 Veeam 服务器应位于备用区域和备份帐户中，如 备份帐户中所述。
Red Hat OpenShift / Kubernetes
可以通过 PX-Backup来备份 IBM Cloud 上的 Red Hat OpenShift 和 Kubernetes 集群。 用于备份的 Portworks 服务器应位于备用区域和备份帐户中，如 备份帐户中所述。
Secrets Manager
密钥管理器可以是 使用 IBM Cloud CLI 备份 和客户提供的自动化。 这些备份应存储在备用区域中的私钥管理器备份实例中，并存储在备份帐户中，如 备份帐户中所述。
Cloud Object Storage
Cloud Object Storage 存储区可以跨区域，跨区域或存储在单个数据中心内。 此外，可以使用 存储区复制来备份 Cloud Object Storage 存储区。 这些备份应存储在备用区域中的 Cloud Object Storage 存储区中，并存储在备份帐户中，如 备份帐户中所述。
Cloudant
Cloudant 是高度可用的 NoSQL DB ，可以在多个区域中配置副本。 此外，可以使用使用客户提供的自动化的 CouchBackup 客户机进行 Cloudant 备份。 这些备份应存储在 Cloud Object Storage 中的备用区域和备份帐户中，如 备份帐户中所述。
Event Streams
Event Streams 是高度可用的 Kafka 即服务。 鉴于事件系统的性质，时间点备份可能没有什么价值。 但是，建议将 镜像到第二个区域 用于灾难恢复。
其他服务
有关备份的更多信息，请参阅特定于服务的文档。
IBM Cloud Framework for Financial Services 中的相关控件
以下 IBM Cloud Framework for Financial Services 控件 与本指南最相关。 不过，除了遵循这里的指导，做好自己的尽职调查，确保你符合要求。
| 系列 | 控件 |
|---|---|
| 应急规划 (CP) | CP-2 应急计划 |
| CP-6 备用存储站点 | |
| CP-7 备用处理站点 | |
| CP-9 信息系统备份 | |
| CP-10 信息系统恢复和重新连接 |