本页面介绍了如何首次激活 Backup and DR 服务并为项目设置配置。
Backup and DR 架构的组成部分
Backup and DR Service 架构通过以下组件实现：
管理控制台：管理控制台充当备份/恢复设备的管理平面。每个备份和灾难恢复部署都包含一个管理控制台，用于管理任意数量的备份/恢复设备。管理控制台部署在备份管理项目中，在部署区域内具有高可用性，可应对可用区服务中断。
备份/恢复设备：备份/恢复设备是一种数据迁移工具，可高效捕获、移动和管理企业内备份数据的生命周期。备份/恢复设备部署在云工作负载的工作负载实体中。
备份和灾难恢复代理：备份和灾难恢复代理调用应用原生 API，以永久增量方式高效捕获生产应用中的数据，并在恢复时提供应用感知功能。代理安装在要保护的应用所在的宿主上。如果您仅保护整个虚拟机或其部分磁盘，则无需使用 Backup and DR 代理。
管理控制台已在服务提供方 VPC 网络中激活。此服务提供方 VPC 使用专用 Google 访问通道与您的项目进行通信。
管理服务器与设备之间、设备之间以及设备与主机代理之间的通信通过双向 TLS 身份验证进行保护。
实现方面的注意事项
以下是一些重要的注意事项，它们会影响您部署 Backup and DR Service 的方式：
贵组织的恢复时间目标 (RTO) 要求是什么？ RTO 是指您能够承受的最长数据丢失时间。例如，如果您的 RTO 为 4 小时，那么您需要在灾难发生后的 4 小时内能够访问数据。
您是否需要集中管理备份？您需要决定是否要集中管理备份。
- 集中式备份管理意味着您可以使用一个管理控制台来管理所有业务线中所有工作负载的备份。这样可以更高效地管理备份，因为您只需管理一个管理控制台。
- 分散式备份管理是指您为每个业务线设置单独的管理控制台。运营模式因组织而异。
您的备份使用情形是什么？您是否需要备份来为生产区域发生灾难时做好灾难恢复准备，还是仅需在本地保护数据就足够了？如果您需要灾难恢复功能，则必须考虑跨区域备份。这意味着将备份存储在多个位置，这样即使某个位置受到灾难影响，您仍然可以访问数据。
工作负载位于单个区域中
区域内的最佳备份策略取决于您的需求。
如果您不需要灾难恢复 (DR)
为了获得最快的性能并降低成本，请在工作负载运行的同一区域中部署管理控制台和备份/恢复设备。将备份映像存储在与工作负载相同的区域中。
如果您还想在异地存储备份副本，则可以将备份存储在其他区域，也可以使用双区域或多区域存储。将备份存储在其他区域会产生网络费用和存储费用。
如果您既需要备份又需要 DR
为了获得最快的性能和最低的费用，请在生产工作负载区域部署一个管理控制台，并在可用于灾难恢复的区域部署第二个管理控制台。
在生产工作负载区域和灾难恢复区域中都部署备份/恢复设备，以最大限度地缩短恢复时间目标 (RTO)。这样可确保在发生灾难时，DR 环境已完全预配置并可供使用。
将备份映像存储在生产区域中，并将副本存储在灾难恢复 (DR) 区域中，或者使用双区域或多区域存储空间。生产区域备份副本可以满足日常备份需求，且性能更快。如果生产区域出现故障，您可以利用复制到灾难恢复区域的数据来恢复工作负载。
工作负载位于多个区域中
跨区域的最佳备份策略取决于您的需求。
如果您不需要灾难恢复 (DR)
为了获得最快的性能并降低成本，请在工作负载运行的某个区域中部署管理控制台。这样一来，您就可以跨所有工作负载和区域进行集中管理。
在运行工作负载的每个区域中部署一个或多个备份/恢复设备。 将备份存储在与工作负载相同的区域中。
如果您还想在异地存储备份副本，则可以将备份存储在其他区域，也可以使用双区域或多区域存储。如果将备份存储在其他区域或多区域，则会产生网络和存储费用。
如果您既需要备份又需要 DR
在每个生产工作负载区域中部署一个管理控制台，并在灾难恢复区域中部署另一个管理控制台。
在生产工作负载区域和灾难恢复区域中都部署备份/恢复设备，以最大限度地缩短恢复时间目标 (RTO)。这样可确保在发生灾难时，灾难恢复环境已完全预配置并可供使用。
将备份存储在生产工作负载区域中，并将副本存储在灾难恢复区域中，或者使用双区域或多区域存储空间。生产区域备份副本可用于满足备份需求。
如果生产区域出现故障，可以使用 DR 中的备份映像来恢复工作负载。
在 Google Cloud 控制台中设置 Backup and DR Service
前往 Google Cloud 控制台，激活 Backup and DR Service API 并为您的账号设置权限：
备份/恢复设备类型
Backup and DR 服务提供针对不同工作负载（Compute Engine 虚拟机、VMware 虚拟机、数据库和文件系统）优化的设备类型。您可以选择最符合自己需求的设备类型。请务必为您的工作负载选择最合适的设备类型。备份/恢复设备投入使用后，会一直运行，随时准备运行和重新运行备份、恢复和其他作业。
Backup and DR Service 提供以下设备类型：
- Compute Engine 虚拟机或 SAP HANA 数据库的标准：如果您只想使用 Persistent Disk 备份 Compute Engine 实例或 SAP HANA 数据库，请选择此选项。默认情况下，此设备会添加 e2-standard-4 机器类型，其 Persistent Disk 的最小容量为 10 GB。此设备最多可管理 5,000 个 Compute Engine 虚拟机。
- 适用于 VMware 虚拟机和其他数据库或资源的标准设备：如果您希望采用标准配置，以支持最佳性能来备份数据库、VMware 虚拟机和其他资源，请选择此选项。默认情况下，此设备会添加 n2-standard-16 机器类型。这样一来，平衡磁盘容量会增加 4 TB，作为最小磁盘容量。此设备最多可管理 1,500 个应用。
适用于 VMware 虚拟机和其他数据库或资源的基本设备：如果您希望获得支持中等性能的基本配置，以备份数据库、VMware 虚拟机和其他资源，请选择此选项。默认情况下，此设备会添加 e2-standard-16 机器类型。此设备最多可管理 1,500 个应用。 您可以选择以下任一类型的磁盘来存储数据。
- 最小容量的永久性磁盘：此选项提供的最小磁盘容量为 10 GB。在此存储类型中，备份将存储为 Persistent Disk 快照，不会占用备份/恢复设备的本地存储空间。
- 标准永久性磁盘：如果您需要高效的块存储，请选择此存储类型。除 Compute Engine 虚拟机外，还建议用于具有中高 I/O 的 Google Cloud VMware Engine 虚拟机、数据库或文件系统应用。这会增加 4 TB 的 Persistent Disk 容量作为最小磁盘容量。
- SSD 永久性磁盘：如果您需要快速块存储，请选择此存储类型。除 Compute Engine 虚拟机外，还建议用于具有极高 I/O 的 Google Cloud VMware Engine、数据库或文件系统应用。这会增加 4 TB 的 Persistent Disk 容量作为最小磁盘容量。
部署设备时，系统会自动创建服务账号，无论设备类型如何。您可以在服务账号页面中查看服务账号。
服务账号的名称将显示在电子邮件地址中，格式为 my-service-account@my-project.iam.gserviceaccount.com，其中 appliance-name 是设备的名称，projectid 是您的 Google Cloud 项目 ID。
选择存储空间类型
备份/恢复设备将备份数据存储在本地设备快照池中。您可以将其复制到对象存储中以进行长期保留。Google Cloud 提供以下三种类型的本地对象存储：
最小容量的永久性磁盘：备份映像以 Persistent Disk 快照的形式存储，不会占用备份/恢复设备的本地存储空间。
标准永久性磁盘：此存储类型提供高效的块存储，从 4 TB Persistent Disk 开始。建议用于具有中高 I/O 的 VMware Engine 和数据库或文件系统应用。
SSD 永久性磁盘：此存储类型提供快速块存储，从 4TB Persistent Disk 开始。建议用于具有极高 I/O 的 Google CloudVMware Engine 虚拟机和数据库，或者是文件系统应用。
您稍后可以扩展磁盘池的容量。
您可以根据预期的数据访问需求，将需要长期保留的备份移动到 Google Cloud Standard、Nearline 和 Coldline 存储空间。
Backup and DR Service 的推荐网络拓扑
Google Cloud 建议在部署 Backup and DR Service 时使用共享 VPC。 通过共享 VPC，组织可以将多个项目中的资源连接到一个公用 VPC (VPC) 网络，让它们能够通过该网络使用内部 IP 安全高效地相互通信。在使用共享 VPC 时，您将某个项目指定为宿主项目，并将一个或多个其他服务项目连接到该项目。宿主项目中的 VPC 网络称为共享 VPC 网络。服务项目中的合格资源可以使用共享 VPC 网络中的子网。
通过共享 VPC，组织管理员可以将创建和管理实例等管理职责委托给服务项目管理员，同时保持对子网、路由和防火墙等网络资源的集中控制。
管理控制台会激活到服务提供方 VPC 网络 VPC 中。此服务提供方 VPC 使用专用 Google 访问通道与您的项目进行通信。此连接的主要目的是让管理控制台和备份/恢复设备交换元数据。备份流量不会通过此链路。不过，管理控制台需要与部署在任何网络中的所有备份/恢复设备通信。
共享 VPC 最佳实践
建议采用以下最佳实践：
连接到管理控制台：最好将服务提供商网络连接到您网络中的共享 VPC。管理控制台的所有流量都会流经此 VPC，因此也会流经宿主项目。通过共享 VPC 为备份和灾难恢复服务预配连接，还可以在运行工作负载的项目（服务项目）与备份和灾难恢复服务之间建立无缝连接。
备份/恢复设备位置：备份/恢复设备必须部署在启用了专用 Google 访问通道的子网中，以便连接到管理控制台。建议采用以下两种策略来选择备份/恢复设备的相应项目：
在中央宿主项目中：在此策略中，Backup and DR Service 被视为 IT 部门的中央服务。中央备份团队负责管理服务的配置。因此，所有备份/恢复设备都在宿主项目中预配，以便中央管理员将所有备份资源整合到一个中央项目中。这种方法的优势在于，可将所有与备份相关的资源及其结算信息整合到一个项目中。
在服务项目中：此策略适用于更加去中心化的团队，这些团队会创建服务项目，并将其管理权限委托给分布式团队。在这种情况下，建议的最佳实践是为下游服务项目预配 VPC。备份/恢复设备安装在这些 VPC 内的服务项目中。这样一来，工作负载和备份/恢复设备就可以位于同一项目中。
专用 Google 访问通道：最佳实践是为安装备份/恢复设备的每个子网启用专用 Google 访问通道。这样可确保备份/恢复设备能够与 Compute Engine、Cloud Storage 和 Cloud Logging 等 API 通信，这对于监控和提醒功能正常运行至关重要。为了简化和增强与 Google Cloud API 的连接，请考虑为
private.googleapis.com配置 DNS 解析，如配置选项摘要部分中所述。此外，还要配置备份/恢复设备的防火墙规则，以允许在 TCP 端口443上连接到 CIDR 范围199.36.153.8/30。
防火墙配置
系统会自动添加以下必需的防火墙规则，以允许入站流量进入 Backup and DR Service。
| 用途 | 来源 | 目标 | 端口 (TCP) |
|---|---|---|---|
| 支持流量（从支持人员到设备） | 运行 SSH 客户端的主机 | 备份/恢复设备 | 26 |
| iSCSI 备份（主机到设备） | 运行 Backup and DR 代理的主机 | 备份/恢复设备 | 3260 |
| StreamSnap 流量（设备到设备） | 备份/恢复设备 | 备份/恢复设备 | 5107 |
| 备份/恢复设备与管理控制台的连接 | 备份/恢复设备 IP 或子网 | *.backupdr.googleusercontent.com | 443 |
如需详细了解如何配置此规则，请参阅准备部署 Backup and DR Service。
对于运行 Backup and DR 代理的任何主机，您都必须手动添加以下 TCP 端口，以允许通过入站流量防火墙规则进行连接。
| 用途 | 来源 | 目标 | 端口 (TCP) |
|---|---|---|---|
| 代理流量（从设备到主机） | 备份/恢复设备 | 运行 Backup and DR 代理的主机 | 5106 |
对于使用 NFS 处理备份流量的主机，或者对于在 VMware Engine 中运行且使用 NFS 进行装载的 ESX 主机，您需要手动添加以下 TCP 和 UDP 端口，以通过入站防火墙规则允许连接。
| 用途 | 来源 | 目标 | 端口 (TCP/UDP) |
|---|---|---|---|
| NFS 备份或装载 | 运行代理的主机或运行装载的 ESXi 主机 | 备份/恢复设备 | 111、756、2049、4001、4045 |
如需查看此操作期间使用的权限列表，请参阅 Backup and DR 安装权限参考。
支持的区域
以下部分列出了管理控制台和备份/恢复设备支持的区域。
管理控制台支持的区域
虽然 Backup and DR Service 可用于备份任何Google Cloud 区域中受支持的工作负载，但管理控制台只能在以下区域中激活：
| 地理区域 | 区域名称 | 区域说明 | |
|---|---|---|---|
| 北美洲 | |||
northamerica-northeast1 * |
蒙特利尔 |
 二氧化碳排放量低
|
|
northamerica-northeast2 |
多伦多 |
二氧化碳排放量低
|
|
us-central1 |
艾奥瓦 |
二氧化碳排放量低
|
|
us-east1 |
南卡罗来纳 | ||
us-east4 |
北弗吉尼亚 | ||
us-east5 |
哥伦布 | ||
us-south1 |
达拉斯 |
二氧化碳排放量低
|
|
us-west1 |
俄勒冈 |
二氧化碳排放量低 |
|
us-west2 |
洛杉矶 | ||
us-west3 |
盐湖城 | ||
us-west4 |
拉斯维加斯 | ||
northamerica-south1 * |
克雷塔罗州 | ||
| 南美洲 | |||
southamerica-east1 |
圣保罗 |
二氧化碳排放量低
|
|
southamerica-west1 |
圣地亚哥 |
二氧化碳排放量低
|
|
| 欧洲 | |||
europe-central2 |
华沙 | ||
europe-north1 |
芬兰 |
二氧化碳排放量低
|
|
europe-southwest1 |
马德里 |
二氧化碳排放量低
|
|
europe-west1 |
比利时 |
二氧化碳排放量低
|
|
europe-west2 |
伦敦 |
二氧化碳排放量低
|
|
europe-west3 |
法兰克福 |
二氧化碳排放量低
|
|
europe-west4 |
荷兰 |
二氧化碳排放量低
|
|
europe-west6 |
苏黎世 |
二氧化碳排放量低
|
|
europe-west8 |
米兰 | ||
europe-west9 |
巴黎 |
二氧化碳排放量低
|
|
europe-west10 |
柏林 |
二氧化碳排放量低
|
|
europe-west12 |
都灵 | ||
| 中东 | |||
me-central1 |
多哈 | ||
me-central2 |
达曼 | ||
me-west1 |
以色列 | ||
| 非洲 | |||
africa-south1 |
约翰内斯堡 | ||
| 亚太地区 | |||
asia-east1 |
台湾 | ||
asia-east2 |
香港 | ||
asia-northeast1 |
东京 | ||
asia-northeast2 * |
大阪 | ||
asia-northeast3 |
首尔 | ||
asia-southeast1 |
新加坡 | ||
asia-southeast2 |
雅加达 | ||
australia-southeast1 |
悉尼 | ||
australia-southeast2 |
墨尔本 | ||
| 印度 | |||
asia-south1 |
孟买 | ||
asia-south2 |
德里 |
* 克雷塔罗、蒙特利尔和大阪各有三个可用区，它们位于一个或两个物理数据中心内。如果极罕见地发生灾难，存储在这些区域的数据可能会丢失。
备份/恢复设备支持的区域
备份/恢复设备可部署到任何Google Cloud 可用区。
工作流服务支持在所列区域中执行备份/恢复设备部署。如果工作流服务在部署了备份/恢复设备的区域中不可用，则 Backup and DR Service 默认在 us-central1 区域中运行工作流（设备本身仍会在您选择的区域中创建）。如果您设置了组织政策来防止在其他区域中创建资源，则必须暂时更新组织政策，以允许在 us-central1 区域中创建资源。部署备份/恢复设备后，您可以限制 us-central1 区域。