Bigtable 备份概览
本页面简要介绍了 Bigtable 备份。这些内容适用于 Bigtable 管理员和开发者。
借助备份，您可以保存表架构和数据的副本，并可在以后通过该备份将内容恢复到新表中。Bigtable 提供两种类型的备份。您创建的备份类型取决于您的灾难恢复 (DR) 要求以及 Bigtable 集群使用的存储类型（HDD 或 SSD）。
- 标准备份经过优化，可长期保留。从标准备份恢复到 SSD 集群时，恢复操作需要 Bigtable 进行额外的优化，才能使表达到生产级性能。如需了解详情，请参阅恢复时的性能
- 热备份可最有效地恢复到生产级性能和低延迟服务。如需了解详情，请参阅热备份
您可以通过以下方式创建备份：
- 启用自动备份功能，让 Bigtable 为您每天创建备份
- 使用 Google Cloud 控制台、gcloud CLI 或 Bigtable 客户端库按需创建备份
- 创建备份的副本
在阅读本页内容之前，您应该先熟悉 Bigtable 概览和管理表。
特性
- 完全集成：备份完全由 Bigtable 服务处理，无需导入或导出。
- 增量：备份会与源表和表的其他备份共享物理存储空间。
- 经济实惠：借助 Bigtable 备份，您可以避免使用其他服务进行导出、存储和导入数据的费用。
- 自动过期：每个备份都有一个用户定义的失效日期，最长可达备份创建后的 90 天。备份的副本最多可存储 30 天。
- 灵活的恢复选项：您可以从创建备份的实例中将备份恢复到另一个实例中的表。
- 自动备份：启用自动备份，让 Bigtable 每天创建备份。
- 热备份：使用可投入生产环境的热备份规划灾难恢复。
使用场景
备份在以下使用场景下非常有用：
- 业务连续性
- 法规遵从
- 测试和开发
- 灾难恢复
请考虑以下灾难恢复场景：
| 目标 | 备份策略 | 恢复策略 |
|---|---|---|
| 防范人为错误 ：您需要始终备份最新的数据，以防意外删除或损坏。 | 确定适合您业务需求的备份创建时间表，例如每天。（可选）定期创建备份的副本，并将其存储在其他项目或区域中，以增强隔离和保护。为进一步增强保护，还可以将备份副本存储在一个访问受限的项目或实例中。 | 通过备份或备份副本将内容恢复到一个新表中，然后将请求重新路由到该新表。 |
| 可用区不可用 ：您需要确保在 Google Cloud 可用区不可用的情况下（虽然这种情况不太可能发生），您的数据仍然可用。 | 启用自动备份功能，让 Bigtable 每天对实例中的每个集群创建备份。或者，定期创建备份，然后定期创建最新备份的副本，并将其存储在位于不同可用区的一个或多个集群上（也可选择将其存储在不同实例或项目中）。 | 如果服务集群所在的可用区变得不可用，可通过远程备份副本将内容恢复到一个新表中，然后将请求重新路由到该新表。 |
| 数据损坏 ：使用备份来恢复表的部分数据，例如在源表出现部分损坏时。 | 启用复制和自动备份，以便在多个区域中创建每日备份，这样，如果某个表在一个集群上损坏，您就有一个或多个备份不会与损坏集群共享存储空间。 | 通过备份将内容恢复到位于新集群或实例的新表中。然后，使用 Bigtable 客户端库或 Dataflow 编写一个应用，该应用从新表中读取数据，然后将数据写回源表。将数据复制到原始表后，便可删除新表。 |
| 快速恢复 ：快速恢复到完整的生产环境性能水平，最大限度地缩短停机时间。 | 始终维护表的近期热备份。 | 通过热备份将内容恢复到一个新表中，然后将请求重新路由到该新表。 |
热备份
热备份是可用于生产环境的备份，经过优化可快速恢复，在恢复后不久从新表读取时延迟时间更短。与使用标准备份进行恢复相比，使用热备份恢复到生产性能的速度更快。
您可以将热备份转换为标准备份，但无法将标准备份转换为热备份。
您无法使用自动备份创建热备份，也无法在 HDD 集群上创建热备份。
使用 Bigtable 备份
可对 Bigtable 备份执行以下操作。在所有情况下，目标项目、实例和集群必须已经存在。您无法在备份操作过程中创建这些资源。
|
||
| 操作 | 目标选项 | |
|---|---|---|
| 创建标准备份 |
|
|
| 创建热备份 |
|
|
| 从标准备份或热备份恢复到新表 |
|
|
| 复制备份1、2 |
|
|
如需了解这些操作以及更新和删除备份等操作的分步说明，请参阅管理备份。
备份存储
您按需创建的表备份会存储在您指定的单个集群上。启用自动备份后，系统会在实例中的每个集群上创建并存储备份。
在创建备份的集群上，表的备份包含创建备份时表中存在的所有数据。备份绝不会大于创建备份时源表的大小。
标准备份是增量备份。标准备份所占用的存储空间量取决于表的大小，以及它将未更改的数据与原始表或同一表的其他备份共享的程度。因此，备份的大小取决于数据与上次备份时的差异大小。
另一方面，热备份是完整的副本，无论源表发生多大更改，在备份时都将占用相同的存储空间量。由于备份采用了经过优化的存储空间，因此被视为热备份，可让您高效地恢复到生产环境的性能水平。
您最多可以为每个集群的每个表创建 150 个备份。
可以删除具有备份的表。为保护备份，您不能删除包含备份的集群，也不能删除任何集群中具有一个或多个备份的实例。
从备份恢复到新表后，备份仍然存在。当不再需要它时，您可以将其删除，也可以让其过期。备份存储空间不计入项目的节点存储空间限制。
备份中的数据会被加密。
保留
您可以为备份指定最长 90 天的保留期限。如果您是创建备份的副本，则该副本的最长保留期限为创建副本后的 30 天。
对于启用了自动备份的表，默认保留期限为 3 天。您可以更改备份的保留期限，使其在创建后最长可保留 90 天。
恢复后存储
通过备份恢复的新表的存储费用与其他所有表相同。
通过备份恢复的表可能不会占用与原始表相同的存储空间，并且在恢复后可能会减小。大小差异取决于源集群和目标集群上压缩发生的时间。
由于压缩是滚动执行的，因此压缩操作可能会在表创建后立即进行。但是，压缩最长可能在一周后才进行。
通过备份恢复的新表不会继承源表的垃圾回收政策。请先在新表中配置垃圾回收政策，然后再开始向表中写入新数据。如需了解详情，请参阅配置垃圾回收。
费用
使用备份时，需支付标准网络费用。您无需为备份操作（包括创建备份、复制备份或从备份恢复）付费。
存储费用
标准备份和热备份的存储费用不同。
标准备份存储费用
如要存储标准备份或备份的副本，您需要按照包含备份或备份副本的集群所在的区域适用的标准备份存储费率付费。
标准备份是表的完整逻辑副本。Bigtable 会在后台优化标准备份存储空间利用率。这种优化意味着标准备份是增量备份，它会尽可能与原始表或表的其他备份共享物理存储空间。由于 Bigtable 内置了存储优化功能，存储标准备份或备份副本的费用有时可能会低于表备份的完整实体副本费用。
在启用了自动备份的复制实例中，存储空间费用可能会更高，因为系统会每天在每个集群上创建一个备份。
热备份存储费用
如要存储热备份，您需要按照包含热备份的集群所在的区域适用的热备份存储费率付费。
由于热备份会存储在就绪状态（已针对快速恢复进行了优化），因此您需要为表的整个逻辑副本的存储付费，而不是像标准备份那样按增量部分付费。
备份复制费用
若在与源备份不同的区域中创建备份的副本，则在将数据复制到目标集群时，需要支付标准网络费用。若在与源备份相同的区域中创建副本，则无需支付网络流量费用。
恢复费用
从备份恢复新表时，您需要支付复制操作的网络费用。如果新表位于使用复制功能的实例中，则您需要为要复制到实例中所有集群的数据支付一次性复制费用。
如果您要恢复到与创建备份的实例不同的实例，并且备份的实例和目标实例在同一区域中没有至少一个集群，则您需要按照标准网络费率，为将数据初始复制到目标集群产生的流量支付费用。
CMEK
在受客户管理的加密密钥 (CMEK) 保护的集群中创建备份时，备份在获取集群的 CMEK 密钥时将固定到密钥的主版本。创建备份后，即使 KMS 密钥已轮替，其密钥和密钥版本也无法修改。
从备份进行恢复时，必须启用备份固定到的密钥版本才能成功执行备份解密过程。对于目标实例中的每个集群，使用 CMEK 密钥的最新主版本来保护新表。如果要从受 CMEK 保护的备份恢复到其他实例，则目标实例也必须受 CMEK 保护，但不需要与源实例具有相同的 CMEK 配置。
复制注意事项
本部分介绍在使用复制的实例中备份和恢复表时要了解的其他概念。
复制和备份
在复制的实例中手动备份表时，请选择要在其中创建和存储备份的集群。对于启用了自动备份的表，系统会对实例中的每个集群创建每日备份。
您无需停止向包含备份的集群写入数据，但您应该了解 Bigtable 如何处理对集群的复制写入。
备份是在创建备份时，存储备份的集群上表的状态副本。尚未从实例中的另一个集群复制的表数据不会包含在备份中。
每个备份都有开始时间和结束时间。在备份操作之前不久或期间发送到集群且写入可能不会包括在备份中。导致这种不确定性的因素有两个：
- 写入可能会发送到表中已复制了备份的部分。
- 对另一个集群的写入可能尚未复制到包含备份的集群。
换句话说，一些时间戳早于备份时间的写入可能不会包括在备份中。
如果这种不一致性不能满足您的业务需求，则可以对写入请求使用一致性令牌，以确保所有复制的写入都包含在备份中。
自动备份过程中创建的复制表的备份并非完全相同的副本，因为备份时间可能会因集群而异。
复制和恢复
将备份恢复到新表时，在目标集群上完成恢复操作后，与实例中其他集群之间的复制将立即开始。
性能
创建备份时，请遵循以下最佳实践，确保性能始终处于最佳状态。
备份性能
创建备份通常不到一分钟，但最多可能需要一个小时。在正常情况下，备份创建不会影响传送性能。
为实现最佳性能，创建单个表备份的频率不能超过每 5 分钟一次。更频繁地创建备份可能会导致传送延迟时间明显延长。
恢复性能
从备份恢复到单集群实例中的表需要几分钟时间。在复制型实例中，恢复时间较长，因为必须将数据复制到所有集群。Bigtable 始终选择最高效的路由来复制数据。
如果您要恢复到与创建备份的实例不同的实例，恢复操作需要的时间会比恢复到同一实例的时间长。如果目标实例在创建备份的集群所在的可用区中没有集群，则尤为如此。
表越大，恢复时间越长。
如果您有一个 SSD 实例，则在优化表时，您一开始可能会遇到较高的读取延迟（即使在恢复完成之后）。您可以在恢复操作期间随时检查状态，以查看优化是否仍在进行中。
如果您要恢复到与创建备份的实例不同的实例，则目标实例可以使用 HDD 或 SSD 存储空间。它不需要使用与源实例相同的存储类型。
访问权限控制机制
IAM 权限控制对备份和恢复操作的访问权限。备份权限是实例级层的，适用于实例中的所有备份。
您用于创建表备份的账号必须有权读取表和在表所在的实例（源实例）中创建备份。
您用于复制备份的账号必须有权读取源备份中的数据并且有权在目标实例和项目中创建备份。
用于从备份恢复新表的账号必须有权在要恢复到的实例中创建表。
| 操作 | 所需的 IAM 权限 |
|---|---|
| 创建备份 | bigtable.tables.readRows、bigtable.backups.create |
| 获取备份 | bigtable.backups.get |
| 列出备份 | bigtable.backups.list |
| 删除备份 | bigtable.backups.delete |
| 更新备份 | bigtable.backups.update |
| 复制备份 | bigtable.backups.read、bigtable.backups.create |
| 通过备份将内容恢复到一个新表中 | bigtable.tables.create、bigtable.backups.restore |
| 获取操作 | bigtable.instances.get |
| 列出操作 | bigtable.instances.get |
最佳实践
在制定备份策略之前，请务必注意以下最佳实践。
创建备份
- 备份表的频率不能超过每 5 分钟一次。
- 在备份使用复制的表时，请考虑以下几个因素，然后再选择存储备份的集群：
- 费用。实例中的一个集群可能位于比其他集群费用更低的区域。
- 邻近应用服务器。您可能需要将备份存储到尽可能靠近传送应用的位置。
- 存储空间利用率。随着备份的累积，您需要有足够的存储空间来存储备份。根据工作负载，您可能有不同大小或不同磁盘用量的集群。这可能会影响您对集群的选择。
- 在使用复制功能的实例中备份表时，如果需要确保所有复制的写入都包含在备份中，请对写入请求使用一致性令牌。
从备份中恢复
- 如果需要从备份中恢复，请提前计划好新表的名称。关键是要提前做好相应准备，不要留到处理问题时再做决定。
- 如果不是因为意外删除而需要恢复表，请确保所有读写操作都已转到新表，然后再删除原始表。
- 如果您打算恢复到其他实例，请先创建目标实例，然后再启动备份恢复操作。
配额和限制
备份和恢复请求与备份存储都受 Bigtable 配额和限制的约束。
限制
以下限制适用于 Bigtable 备份：
常规
- 您无法直接从备份中读取。
- 备份是特定时间单个集群中的表版本。备份不表示一致状态。这同样适用于不同集群中同一表的备份。
- 一次操作无法备份多个表。
- 无法将 Bigtable 备份导出、复制或移动到其他服务，例如 Cloud Storage。
- Bigtable 备份仅包含 Bigtable 数据，不会与其他 Google 服务的备份集成或关联。
正在恢复
- 无法通过备份将内容恢复到现有表。
- 只能恢复到已存在的实例。使用备份进行恢复时，Bigtable 不会创建新实例。如果恢复请求中指定的目标实例不存在，恢复操作将失败。
- 如果使用备份恢复到 SSD 集群中的表，然后删除新恢复的表，则可能需要一些时间才能完成对该表的删除，因为 Bigtable 会等待表优化完成。
正在复制
- 无法创建将在 24 小时内到期的备份的副本。
- 无法创建备份副本的副本。
CMEK
- 受 CMEK 保护的备份必须恢复到受 CMEK 保护的实例中的新表。
- 如要创建受 CMEK 保护的备份的副本，目标集群也必须受 CMEK 保护。