Backup and DR Service 支持通过Google Cloud 控制台备份 Cloud SQL 实例、AlloyDB 集群、Compute Engine 实例和单个磁盘。如需了解备份和恢复这些资源的程序，请参阅相关文档。如果您的所有工作负载都属于这些类别，则无需备份/恢复设备。
若要备份和恢复在 Compute Engine 实例内运行的 VMware 虚拟机以及 SAP HANA、IBM Db2、Oracle 和 Microsoft SQL Server 数据库，需要使用 Backup and DR 设备管理控制台以及一个或多个备份/恢复设备。使用此设置时，您需要选择与所备份的应用相匹配的备份/恢复设备大小。此设置的流程包括创建管理服务器、部署设备，然后使用设备管理控制台配置备份时间表，并定义备份内容和位置。
如需概览确保最有效地使用备份/恢复设备的策略，请参阅备份/恢复设备部署注意事项。
本页面介绍了如何首次激活 Backup and DR Service，以及如何为项目设置配置。
备份/恢复设备架构的组成部分
Backup and DR Service 架构通过以下组件实现：
Google Cloud 控制台： Google Cloud 控制台包含 Backup and DR 产品，可用于集中管理 Persistent Disk 保险柜备份、Compute Engine 实例的备份方案，以及这些产品中的 Cloud SQL 增强型备份。
设备管理控制台：设备管理控制台充当备份/恢复设备的管理平面。每个 Backup and DR 部署都包含一个设备管理控制台，用于管理任意数量的备份/恢复设备。设备管理控制台部署在备份管理项目中，在部署区域内具有高可用性，可应对地区性服务中断。
备份/恢复设备：备份/恢复设备是一种数据移动工具，可用于高效地捕获、移动备份数据，并管理企业内备份数据的生命周期。备份/恢复设备部署在云工作负载的工作负载实体中。如果您部署了多个备份/恢复设备，则每个设备都必须与一个唯一的服务账号相关联。
Backup and DR 代理：Backup and DR 代理会调用应用原生 API，以永久增量方式高效捕获生产应用中的数据，并在恢复时提供应用感知功能。代理安装在要保护的应用所在的宿主机上。如果您仅保护整个虚拟机或其部分磁盘，则无需使用 Backup and DR 代理。
设备管理控制台已在服务提供方 VPC 网络中激活。此服务提供方 VPC 使用专用 Google 访问通道与您的项目进行通信。
管理服务器与设备之间、设备之间以及设备与主机代理之间的通信通过双向 TLS 身份验证进行保护。
在 Google Cloud 控制台中设置 Backup and DR Service
前往 Google Cloud 控制台，激活 backupdr API 并为您的账号设置权限：
备份/恢复设备类型
Backup and DR Service 提供针对不同工作负载（Compute Engine 虚拟机、VMware 虚拟机、数据库和文件系统）优化的设备类型。您可以选择最符合自己需求的设备类型。请务必为您的工作负载选择最合适的设备类型。备份/恢复设备投入使用后，会一直持续运行，随时准备好运行和重新运行备份、恢复和其他作业。
Backup and DR Service 提供以下设备类型：
- 适用于 VMware 虚拟机和其他数据库或资源的标准设备：此 n2-standard-16 机器类型支持最佳性能，可用于备份生产数据库、VMware 虚拟机和其他资源。此设备在部署时会增加 4 TB 的均衡磁盘容量，您还可以再添加 63 个 4 TB 的磁盘。此设备最多可管理 1,500 个应用和 5,000 个每日快照。
- 适用于 Compute Engine 虚拟机或 SAP HANA 数据库的标准：这种 e2-standard-4 机器类型最适合备份 Compute Engine 实例、Cloud SQL 实例、AlloyDB 集群以及使用 Persistent Disk 进行备份的数据资源：配置为使用 Persistent Disk 的 IBM Db2 和 SAP HANA 数据库。此设备类型的 Persistent Disk 容量下限为 10 GB。此设备最多可管理 5,000 个 Compute Engine 和 Cloud SQL 实例、AlloyDB 集群以及基于 Persistent Disk 的数据应用。
适用于 VMware 虚拟机和其他数据库或资源的基本设备：此 e2-standard-16 机器类型支持中等性能，可用于备份数据库、VMware 虚拟机和其他资源。此设备最多可管理 1,500 个应用和 5,000 个每日快照。此设备在部署时会添加 4 TB 的标准磁盘容量，您还可以添加 63 个额外的 4 TB 磁盘，这些磁盘的类型如下：
- 最小容量的永久性磁盘：此选项提供的最小磁盘容量为 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 容量作为最小磁盘容量。
部署设备时，系统会自动创建服务账号，无论设备类型如何。您可以在服务账号页面中查看服务账号。
服务账号的名称将显示在电子邮件地址中，格式如下：
APPLIANCE_NAME@PROJECT_ID.
替换以下内容：
- APPLIANCE_NAME：备份/恢复设备的名称。
- PROJECT_ID：您的 Google Cloud 项目（来源）的 ID。
您可以根据预期的数据访问需求，将需要长期保留的备份移至 Standard、Nearline 和 Coldline Storage。
防火墙配置
系统会自动添加以下必需的防火墙规则，以允许入站流量进入 Backup and DR Service。
| 用途 | 来源 | 目标 | 端口 (TCP) |
|---|---|---|---|
| 支持流量（从支持人员到设备） | SSH_CLIENT_IP | 备份/恢复设备 | 26 |
| iSCSI 备份（主机到设备） | AGENT_HOST_IP | 备份/恢复设备 | 3260 |
| StreamSnap 流量（设备到设备） | SOURCE_APPLIANCE_IP | 备份/恢复设备 | 5107 |
| 备份/恢复设备与设备管理控制台的连接 | APPLIANCE_IP | *.backupdr.googleusercontent.com | 443 |
替换以下内容：
- SSH_CLIENT_IP：运行 SSH 客户端的主机的 IP 地址。
- AGENT_HOST_IP：运行 Backup and DR 代理的主机的 IP 地址。
- SOURCE_APPLIANCE_IP：源设备的 IP 地址。
- APPLIANCE_IP：备份/恢复设备的 IP 地址或子网。
如需详细了解如何配置此规则，请参阅准备部署 Backup and DR Service。
对于运行 Backup and DR 代理的任何主机，您都必须手动添加以下 TCP 端口，以允许通过入站流量防火墙规则进行连接。
| 用途 | 来源 | 目标 | 端口 (TCP) |
|---|---|---|---|
| 代理流量（设备到主机） | 备份/恢复设备 | 运行 Backup and DR 代理的主机 | 5106 |
对于使用 NFS 处理备份流量的主机，或者对于在 Google Cloud 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-north2 |
斯德哥尔摩 |
二氧化碳排放量低
|
|
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 |
德里 |
* 克雷塔罗 (northamerica-south1)、蒙特利尔 (northamerica-northeast1) 和大阪 (asia-northeast2) 不支持可用区隔离。这意味着，这些区域中的多个可用区可能并非位于物理上分离的数据中心园区内。因此，单个局部物理灾难事件可能会影响同一区域内的多个可用区，从而增加数据丢失的风险，而支持可用区隔离的区域则不会出现这种情况。
备份/恢复设备支持的区域
备份/恢复设备可部署到任何Google Cloud 可用区。
工作流服务支持在所列区域中执行备份/恢复设备部署。如果工作流服务在部署了备份/恢复设备的区域中不可用，则 Backup and DR Service 默认在 us-central1 区域中运行工作流（设备本身仍会在您选择的区域中创建）。如果您设置了组织政策，以防止在其他区域中创建资源，则必须暂时更新组织政策，以允许在 us-central1 区域中创建资源。部署备份/恢复设备后，您可以限制 us-central1 区域。