数据的灾难恢复场景

Last reviewed 2022-06-10 UTC

本文档是介绍 Google Cloud 中的灾难恢复 (DR) 的系列文章中的第三篇。本部分讨论了备份和恢复数据的场景。

该系列包含以下部分：

简介

您的灾难恢复计划必须指定如何才能避免在灾难期间丢失数据。这里的术语“数据”涉及两种场景。数据库、日志数据和其他数据类型的备份和恢复符合以下场景之一：

  • 数据备份。备份数据本身包括将数量不等的数据从一个位置复制到另一个位置。作为恢复计划的一部分，备份用于从数据损坏中恢复。您可以在生产环境中直接恢复到某个已知的良好状态；或者如果生产环境中断，您可以恢复灾难恢复环境中的数据。通常，数据备份具有小到中等的 RTO 值和较小的 RPO 值。
  • 数据库备份。数据库备份稍微复杂一些，因为它们通常涉及恢复到某个时间点。因此，除了考虑如何备份和恢复数据库备份以及确保恢复数据库系统建立生产配置（相同版本、已建立镜像的磁盘配置）的镜像之外，还需要考虑如何备份事务日志。在恢复期间，当您恢复了数据库功能后，必须应用最新的数据库备份，然后应用上次备份后备份的已恢复事务日志。由于数据库系统固有的复杂因素（例如生产和恢复系统之间的版本必须匹配），您需要采用优先考虑高可用性的方法，最大限度减少从可能导致数据库服务器不可用的情况中恢复的时间，实现更小的 RTO 和 RPO 值。

本文档的其余部分将讨论几个示例来说明如何为数据和数据库设计一些场景，帮助您实现 RTO 和 RPO 目标。

生产环境在本地

在此场景中，您的生产环境在本地，您的灾难恢复计划会将 Google Cloud 作为恢复站点。

数据备份和恢复

您可以使用许多策略来实现定期将数据从本地备份到 Google Cloud 的过程。本部分介绍两种最常见的解决方案。

解决方案 1：使用计划任务备份到 Cloud Storage

灾难恢复组件：

  • Cloud Storage

用于备份数据的一个选项是创建运行脚本或应用的计划任务，以将数据传输到 Cloud Storage。您可以使用 gsutil 命令行工具或使用某个 Cloud Storage 客户端库自动执行将数据备份到 Cloud Storage 的过程。例如，以下 gsutil 命令将源目录中的所有文件复制到指定存储桶。

gsutil -m cp -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

以下步骤概述了如何使用 gsutil 工具实现备份和恢复过程。

  1. 在要从中上传数据文件的本地机器上安装 gsutil。
  2. 创建存储桶，将其作为数据备份的目标。
  3. 采用 JSON 格式为专用服务账号生成服务账号密钥。此文件用于将凭据传递给 gsutil（作为自动脚本的一部分）

  4. 将服务账号密钥复制到本地机器，在此机器中运行用于上传备份的脚本。

  5. 创建 IAM 政策以限制谁可以访问存储桶及其对象。（包括专门为此目的创建的服务账号和本地运维人员账号）。如需详细了解用于访问 Cloud Storage 的权限，请参阅 gsutil 命令的 IAM 权限。

  6. 测试您是否可以上传和下载目标存储桶中的文件。

  7. 按照为数据传输任务编写脚本中的说明来设置计划脚本。

  8. 配置恢复过程，该过程使用 gsutil 将数据恢复到 Google Cloud 上的灾难恢复环境。

您还可以使用 gsutil rsync 命令在数据与 Cloud Storage 存储桶之间进行实时增量同步。

例如，以下 gsutil rsync 命令通过复制任何缺失的文件或对象已更改的数据，使 Cloud Storage 存储桶的内容与源目录中的内容保持相同。如果与连续备份会话之间的数据量相比，源数据整体数据量相对较小，那么使用 gsutil rsync 可能比使用 gsutil cp 更高效。而这反过来也会产生更频繁的备份计划，从而导致 RPO 值较低。

gsutil -m rsync -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

如需了解详情，请参阅从主机托管或本地存储传输，其中介绍了优化传输过程的方法。

解决方案 2：通过 Transfer service for on-premises data 备份到 Cloud Storage

灾难恢复组件：

  • Cloud Storage
  • Transfer service for on-premises data

跨网络传输大量数据通常需要仔细规划和稳健的执行策略。开发可扩缩、可靠且可维护的自定义脚本非常重要。自定义脚本通常可以降低 RPO 值，甚至增大数据丢失的风险。

实现大规模数据转移的一种方法是使用 Transfer Service for On Premises Data。这是一种可伸缩、可靠的托管式服务，您可以凭借其将大量数据从数据中心转移到 Cloud Storage 存储桶，而无需投资工程团队或购买转移解决方案。

解决方案 3：使用合作伙伴网关解决方案备份到 Cloud Storage

灾难恢复组件：

  • Cloud Interconnect
  • Cloud Storage 分层存储

本地应用通常与第三方解决方案集成，可用作数据备份和恢复策略的一部分。这些解决方案通常采用分层存储模式，借助此模式，您可在更快的存储空间上获得最新的备份，并将旧备份慢慢迁移到更便宜（更慢）的存储空间。将 Google Cloud 用作目标时，您可以将多个存储类别选项作为较慢层的等效选项。

若要实现此模式，可在本地存储和 Google Cloud 之间使用合作伙伴网关，以便将数据传输到 Cloud Storage。下图说明了此配置，其中包含一个合作伙伴解决方案来管理从本地 NAS 设备或 SAN 进行的转移作业。

显示使用专用互连连接到 Google Cloud 的本地数据中心的架构图。

如果发生故障，则必须将要备份的数据恢复到灾难恢复环境。灾难恢复环境用于处理生产流量，直到您能够还原到生产环境。如何实现这一目标取决于您的应用以及合作伙伴解决方案及其架构。（灾难恢复应用文档讨论了一些端到端场景。）

如需有关如何将数据从本地转移到 Google Cloud 的详细指南，请参阅将大型数据集转移到 Google Cloud。

如需详细了解合作伙伴解决方案，请查看 Google Cloud 网站上的合作伙伴页面。

数据库备份和恢复

您可以使用许多策略来实现将数据库系统从本地恢复到 Google Cloud 的过程。本部分介绍两种最常见的解决方案。

本文档不会详细讨论第三方数据库中包含的各种内置备份和恢复机制。本部分提供常规指导信息，这些信息将在我们在此讨论的解决方案中实现。

解决方案 1：使用 Google Cloud 上的恢复服务器进行备份和恢复

  1. 采用数据库管理系统的内置备份机制创建数据库备份。
  2. 连接本地网络和 Google Cloud 网络。
  3. 创建 Cloud Storage 存储桶作为数据备份的目标。
  4. 使用 gsutil 或合作伙伴网关解决方案将备份文件复制到 Cloud Storage（请参阅之前在数据备份和恢复部分中讨论的步骤）。如需了解详情，请参阅将大数据集转移到 Google Cloud。
  5. 将事务日志复制到 Google Cloud 上的恢复站点。备份事务日志有助于保持较小的 RPO 值。

配置此备份拓扑后，必须确保可以恢复到 Google Cloud 上的系统。此步骤通常不仅包括将备份文件恢复到目标数据库，而且还包括重放事务日志以获得最小的 RTO 值。典型的恢复顺序如下：

  1. 在 Google Cloud 上创建数据库服务器的自定义映像。数据库服务器的映像配置应与本地数据库服务器相同。
  2. 实现将本地备份文件和事务日志文件复制到 Cloud Storage 的过程。如需了解示例实现方法，请参阅解决方案 1。
  3. 从自定义映像启动最小的实例，并挂接所需的任何永久性磁盘。
  4. 将永久性磁盘的自动删除标志设置为 false。
  5. 按照数据库系统中用于恢复备份文件的说明，应用之前复制到 Cloud Storage 的最新备份文件。
  6. 应用已复制到 Cloud Storage 的最新一组事务日志文件。
  7. 将最小实例替换为能够接受生产流量的更大实例。
  8. 将客户端切换为指向 Google Cloud 中已恢复的数据库。

当生产环境再次运行并且可以支持生产工作负载时，您可以逆向执行用以故障转移到 Google Cloud 恢复环境的步骤。返回生产环境的典型顺序如下：

  1. 备份在 Google Cloud 上运行的数据库。
  2. 将备份文件复制到生产环境。
  3. 将备份文件应用在生产数据库系统。
  4. 防止客户端连接到 Google Cloud 中的数据库系统；例如，可通过停止数据库系统服务做到这点。从此时起，直到完成生产环境的恢复之前，您的应用将不可用。
  5. 将任何事务日志文件复制到生产环境，并应用它们。
  6. 将客户端连接重定向到生产环境。

解决方案 2：复制到 Google Cloud 上的备用服务器

如需实现非常小的 RTO 和 RPO 值，其中一种方法是将数据（在某些情况下为实时数据库状态）复制（而不仅仅是备份）到数据库服务器的热备用数据库。

  1. 连接本地网络和 Google Cloud 网络。
  2. 在 Google Cloud 上创建数据库服务器的自定义映像。数据库服务器的映像配置应与本地数据库服务器的配置相同。
  3. 从自定义映像启动实例，并挂接所需的任何永久性磁盘。
  4. 将永久性磁盘的自动删除标志设置为 false。
  5. 按照特定于数据库软件的说明，配置本地数据库服务器和 Google Cloud 中目标数据库服务器之间的复制。
  6. 客户端在正常操作中配置为指向本地的数据库服务器。

配置此复制拓扑后，将客户端切换为指向 Google Cloud 网络中运行的备用服务器。

如果已备份生产环境并且能够支持生产工作负载，则必须将生产数据库服务器与 Google Cloud 数据库服务器重新同步，然后将客户端切换为指向生产环境。

生产环境是 Google Cloud

在这种场景中，您的生产环境和灾难恢复环境都在 Google Cloud 上运行。

数据备份和恢复

数据备份的常见模式是使用分层存储模式。如果您的生产工作负载在 Google Cloud 上，分层存储系统如下图所示。您可将数据迁移到存储成本较低的层，因为不大可能需要访问备份数据。

灾难恢复组件：

显示伴随数据从永久性磁盘迁移到 Nearline 和 Coldline 时映像费用降低的概念图。

由于 Nearline、Coldline 和 Archive 存储类别用于存储不经常访问的数据，因此如果您检索存储在这些类别中的数据或元数据，将需要支付额外费用，您还需要支付最短存储期限费用。

数据库备份和恢复

如果您使用自行管理的数据库（例如，您在 Compute Engine 实例上安装的 MySQL、PostgreSQL 或 SQL Server），也存在与本地管理生产数据库同样的运行问题，但您不再需要管理底层基础架构。

您可以使用适当的灾难恢复组件功能来设置高可用性配置，以保持较小的 RTO 值。您可以设计数据库配置，以便可以恢复到尽可能接近灾难前状态的状态；这有助于保持较小的 RPO 值。Google Cloud 提供了多种适用于此场景的选项。

本部分讨论为 Google Cloud 上自行管理的数据库设计数据库恢复架构的两种常用方法。

在不同步状态的情况下恢复数据库服务器

常见模式是启用无需与热备用系统同步系统状态的数据库服务器的恢复操作。

灾难恢复组件：

  • Compute Engine
  • 代管实例组
  • Cloud Load Balancing（内部负载均衡）

下图说明了处理此场景的示例架构。通过实现此架构，您的灾难恢复计划可自动对故障做出反应，无需手动恢复。

显示从一个区域的永久性磁盘获取永久性磁盘映像的架构图

以下步骤概述了如何配置此场景：

  1. 创建 VPC 网络。

  2. 通过执行以下操作，创建使用数据库服务器配置的自定义映像：

    1. 配置服务器，以便将数据库文件和日志文件写入附加的标准永久性磁盘。
    2. 从挂接的永久性磁盘创建快照。
    3. 配置启动脚本以使用快照创建永久性磁盘并装载磁盘。
    4. 创建启动磁盘的自定义映像。

  3. 创建使用该映像的实例模板。

  4. 使用实例模板配置目标大小为 1 的托管式实例组。

  5. 使用 Cloud Monitoring 指标配置健康检查。

  6. 使用托管式实例组配置内部负载均衡。

  7. 配置计划任务以定期创建永久性磁盘的快照。

如果需要更换数据库实例，此配置将自动执行以下操作：

  • 打开同一个可用区中另一个正确版本的数据库服务器。
  • 将包含最新备份和事务日志文件的永久性磁盘附加到新创建的数据库服务器实例。
  • 最大限度减少重新配置与数据库服务器通信以响应事件的客户端的操作。
  • 确保应用于生产数据库服务器的 Google Cloud 安全控制措施（IAM 政策、防火墙设置）适用于已恢复的数据库服务器。

由于替换实例使用实例模板创建，因此应用于原始模板的控件将应用于替换实例。

此场景利用了 Google Cloud 中提供的一些高可用性功能；您不必启动任何故障切换步骤，因为这些步骤会在灾难发生时自动执行。内部负载均衡器确保即使需要替换实例，也会将同一 IP 地址用于数据库服务器。实例模板和自定义映像可确保替换实例的配置与其替换的实例完全相同。通过为永久性磁盘定期拍摄快照，可确保通过快照重新创建磁盘并将其附加到替换实例时，替换实例将使用根据快照频率指定的 RPO 值恢复的数据。在此架构中，还会自动恢复已写入永久性磁盘的最新事务日志文件。

代管式实例组提供更高级的 HA 功能。它提供了对应用或实例级别的故障作出反应的机制，如果发生任何这些情况，您不必手动干预，系统会自动为您执行操作。将目标大小设置为 1 可确保您只在代管式实例组中运行一个活跃实例来处理流量。

标准永久性磁盘是分区的，因此如果出现区域故障，则需要使用快照来重新创建磁盘。快照还可以跨区域使用，这使得您不仅可以在同一区域内恢复磁盘，还可以将磁盘恢复到其他区域。

此配置的变体是使用地区级永久性磁盘而不是标准永久性磁盘。在这种情况下，您无需在恢复步骤中恢复快照。

您选择的变体取决于您的预算以及 RTO 和 RPO 值。

如需详细了解为 Google Cloud 上的高可用性和灾难恢复场景设计的数据库配置，请参阅以下内容：

从大型数据库的部分损坏中恢复

如果您使用的数据库能够存储 PB 级数据，您可能会遇到影响某些数据但不会影响所有数据的中断。在这种情况下，您希望最大限度减少需要恢复的数据量；您不需要（或不希望）为了恢复部分数据而恢复整个数据库。

您可以采用多种缓解策略：

  • 在特定时间段将您的数据存储在不同表中。此方法可确保您只需将数据子集恢复到新表，而不是整个数据集。

  • 将原始数据存储在 Cloud Storage 上。您可以使用此方法创建新表并重新加载未损坏的数据。您可以在其中调整应用以指向新表。

此外，如果您的 RTO 允许，您可以通过在将未损坏的数据恢复到新表之前让应用保持脱机状态来防止访问包含损坏数据的表。

Google Cloud 上的代管式数据库服务

本部分讨论可用于为 Google Cloud 上的代管式数据库服务实现适当备份和恢复机制的一些方法。

代管式数据库是为实现扩缩而设计的，因此您了解的与传统 RDMBS 相关的传统备份和恢复机制通常不可用。与自行管理的数据库一样，如果您使用的数据库能够存储 PB 级数据，则希望最大限度减少在灾难恢复场景中需要恢复的数据量。每个代管式数据库都有许多策略可帮您实现此目标。

Bigtable 提供 Bigtable 复制功能。在发生区域性或地区性故障时，复制的 Bigtable 数据库可比单个集群提供更高的可用性、更大的读取吞吐量、更高的耐用性以及更出色的恢复能力。

Bigtable 备份是一项托管式服务，可让您保存表架构和数据的副本，以便稍后从备份恢复到新表。

您还可以将 Bigtable 中的表导出为一系列 Hadoop 序列文件。然后，您可以将这些文件存储在 Cloud Storage 中，或使用它们将数据导回到另一个 Bigtable 实例中。您可以跨 Google Cloud 单个地区内的区域异步复制 Bigtable 数据集。

BigQuery。如果要将数据归档，可以利用 BigQuery 的长期存储。如果一个表连续 90 天未发生修改，则该表的存储价格会自动下降 50%。某表被视为长期存储后，不会出现性能、耐用性、可用性和任何其他功能方面的降级。但是，如果表发生了修改，价格会恢复到常规的存储价格，并重新开始 90 天倒计时。

BigQuery 会复制到单个区域中的两个可用区，但这对避免表损坏没有任何帮助。因此，您需要制定一个计划，以便能够从该场景中恢复。例如，您可以：

  • 如果在 7 天内发生损坏，则查询过去某个时间点的表，以使用快照修饰器将表恢复到损坏之前的状态。
  • 从 BigQuery 导出数据，并创建一个包含导出数据但不含损坏数据的新表。
  • 在特定时间段将您的数据存储在不同表中。此方法可确保您只需将数据子集恢复到新表，而不是整个数据集。
  • 在特定时间段内创建数据集副本。如果发生数据损坏事件超出了时间点查询可以捕获的时间点（例如，超过 7 天之前），您可以使用这些副本。您也可以将数据集从一个区域复制到另一个区域，以确保在区域发生故障时的数据可用性。
  • 将原始数据存储在 Cloud Storage 上，这使您可以创建新表并重新加载未损坏的数据。您可以在其中调整应用以指向新表。

Firestore。您可以通过托管式导出和导入服务使用 Cloud Storage 存储桶导入和导出 Firestore 实体。您随后可以实现一个可用于恢复意外删除的数据的过程。

Cloud SQL。如果您使用全代管式 Google Cloud MySQL 数据库 Cloud SQL，则应为您的 Cloud SQL 实例启用自动备份和二进制日志记录。通过此方法，您可以执行时间点恢复，从而从备份中恢复数据库并将其恢复到新的 Cloud SQL 实例中。如需了解详情，请参阅 Cloud SQL 备份和恢复。

您还可以在高可用性配置和跨区域副本中配置 Cloud SQL，以便在发生可用区级或区域级故障时可以最大限度地延长正常运行时间。

如果您为 Cloud SQL 启用了近乎零停机时间的计划内维护，则可以通过在 Cloud SQL for MySQL 和 Cloud SQL for PostgreSQL 上模拟近乎零停机时间的计划内维护事件，来评估维护事件对实例的影响。

Spanner。您可以使用 Dataflow 模板将数据库完全导出到 Cloud Storage 存储桶中的一组 Avro 文件，并使用另一个模板将导出的文件重新导入到新的 Spanner 数据库。

对于更多受控备份，可以使用 Dataflow 连接器编写代码，以在 Dataflow 流水线中读取并将数据写入 Spanner。例如，您可以使用连接器将数据作为备份目标从 Spanner 复制到 Cloud Storage 中。从 Spanner 读取数据（或写回数据）的速度取决于配置的节点数。 这对您的 RTO 值有直接影响。

Spanner 提交时间戳功能允许您仅选择自上次完整备份之后添加或修改的行，因此对增量备份非常有用。

对于托管式备份，Spanner 备份和恢复使您可以创建一致的备份，该备份可保留长达 1 年。RTO 值低于 导出，因为恢复操作直接装载备份，而无需复制数据。

对于小 RTO 值，您可以设置一个热备用 Spanner 实例，该实例已配置满足存储和读写吞吐量要求所需的最小节点数。

Spanner 时间点恢复 (PITR) 允许您从过去的特定时间点恢复数据。例如，如果运维人员意外写入数据或应用发布损坏数据库，您可以使用 PITR 从过去某个时间点恢复数据（最多 7 天）。

Cloud Composer。您可以使用 Cloud Composer（Apache Airflow 的代管版本）来安排多个 Google Cloud 数据库的定期备份，还可以创建一个按计划（例如每天）运行的有向无环图 (DAG)，以将数据复制到另一个项目、数据集或表（取决于所使用的解决方案），或将数据导出到 Cloud Storage。

可以使用多种 Cloud Platform 运算符完成数据导出或复制。

例如，您可以创建 DAG 以执行以下任何操作：

生产环境为另一个云

在这种场景中，您的生产环境使用另一个云提供商，而您的灾难恢复计划涉及将 Google Cloud 用作恢复站点。

数据备份和恢复

在对象存储之间转移数据是灾难恢复场景的常见用例。Storage Transfer Service 与 Amazon S3 兼容，是将对象从 Amazon S3 转移到 Cloud Storage 的推荐方法。

您可以配置转移作业，通过指定基于文件创建日期的高级过滤条件、文件名过滤条件以及您希望转移数据的时段，安排从数据源到数据接收器的定期同步。要实现所需的 RPO，您必须考虑以下因素：

  • 变化率。在给定时间内生成或更新的数据量。变化率越高，在每个增量转移周期将更改传输到目标所需的资源越多。

  • 转移性能。传输文件所需的时间。对于大型文件传输，这通常取决于源和目标位置之间的可用带宽。但是，如果转移作业包含大量小文件，则 QPS 可能会成为限制因素。在这种情况下，只要有足够的可用带宽，您就可以安排多个并发作业来扩缩性能。我们建议您使用真实数据代表性数据来衡量转移性能。

  • 频率。备份作业之间的时间间隔。自上次安排转移作业时，目标位置的数据新鲜度是最新的。因此，连续传输作业之间的时间间隔不会超过 RPO 目标。例如，如果 RPO 目标为 1 天，则转移作业必须每天至少安排一次。

  • 监控和提醒。Storage Transfer Service 会就各种事件提供 Pub/Sub 通知。我们建议您订阅这些通知，以便处理意外故障或作业完成时间的变化。

将数据从 AWS 迁移到 Google Cloud 的另一个选择是使用 boto，这是一个与 Amazon S3 和 Cloud Storage 兼容的 Python 工具。它可以作为插件安装到 gsutil 命令行工具中。

数据库备份和恢复

本文档不会详细讨论第三方数据库中包含的各种内置备份和恢复机制，或其他云服务商使用的备份和恢复技术。如果要通过计算服务运行非代管式数据库，可以利用生产云服务商提供的高可用性功能。您可以对其进行扩展，以将高可用性部署合并到 Google Cloud，或将 Cloud Storage 作为数据库备份文件冷存储的最终目标。

后续步骤