Bigtable 备份概览
本页面简要介绍了 Bigtable 备份。这些内容适用于 Bigtable 管理员和开发者。
借助 Bigtable 备份，您可以保存表架构和数据的副本，稍后再从备份恢复到新表。您可以手动创建备份，也可以启用自动备份，让 Bigtable 创建每日备份。您还可以创建备份的副本。
在阅读本页内容之前，您应该先熟悉 Bigtable 概览和管理表。
特性
- 完全集成：备份完全由 Bigtable 服务处理，无需导入或导出。
- 增量：备份与源表和其他备份共享物理存储空间。
- 经济实惠：借助 Bigtable 备份，您可以避免使用其他服务进行导出、存储和导入数据的费用。
- 自动过期：每个备份都有一个用户定义的失效日期，最长可达备份创建后的 90 天。备份的副本最多可存储 30 天。
- 灵活的恢复选项：您可以从创建备份的实例中将备份恢复到另一个实例中的表。
- 自动备份：启用自动备份，让 Bigtable 创建每日备份。
使用场景
备份在以下使用场景下非常有用：
- 业务连续性
- 法规遵从
- 测试和开发
- 灾难恢复
请考虑以下灾难恢复场景：
| 目标 | 备份策略 | 恢复策略 |
|---|---|---|
| 防范人为错误：您需要始终备份最新的数据，以防意外删除或损坏。 | 确定适合您业务需求的备份创建时间表，例如每天。（可选）定期创建备份的副本，并将其存储在其他项目或区域中，以增强隔离和保护。为进一步增强保护，还可以将备份副本存储在一个访问受限的项目或实例中。 | 通过备份或备份副本将内容恢复到一个新表中，然后将请求重新路由到该新表。 |
| 可用区不可用：您需要确保在 Google Cloud 可用区不可用的情况下（虽然这种情况不太可能发生），您的数据仍然可用。 | 定期创建备份，例如每天。然后，定期创建最新备份的副本，并将其存储在位于不同可用区的一个或多个集群上（也可选择将其存储在不同实例或项目中）。 | 如果服务集群所在的可用区变得不可用，可通过远程备份副本将内容恢复到一个新表中，然后将请求重新路由到该新表。 |
| 数据损坏：使用备份来恢复表的部分数据，例如在源表出现部分损坏时。 | 定期创建数据的备份。 | 通过备份将内容恢复到位于新实例的新表中。然后，使用 Bigtable 客户端库或 Dataflow 编写一个应用，该应用从新表中读取数据，然后将数据写回源表。将数据复制到原始表后，便可删除新表。 |
使用 Bigtable 备份
可对 Bigtable 备份执行以下操作。在所有情况下，目标项目、实例和集群必须已经存在。您无法在备份操作过程中创建这些资源。您无法创建备份副本的副本。
| 操作 | 目标选项 |
|---|---|
| 创建备份 |
|
| 通过备份将内容恢复到一个新表中 |
|
| 复制备份 |
|
如需了解这些操作以及更新和删除备份等操作的分步说明，请参阅管理备份。
请使用以下工具来处理 Bigtable 备份：
- Google Cloud 控制台
- Google Cloud CLI
- Cloud Bigtable 客户端库
您还可以直接访问 Cloud Bigtable Admin API，但我们强烈建议您仅在无法使用对 API 进行备份调用的 Cloud Bigtable 客户端库时，才这样做。
Bigtable 备份的工作原理
创建备份涉及了解 Bigtable 中的备份存储和保留。
备份存储
您可以手动创建表备份，也可以启用自动备份，让 Bigtable 进行每日备份。表备份存储在实例中的集群上。如果是手动备份，您的表备份将存储在您所选实例中的一个集群上。启用自动备份后，表备份会存储在实例中的每个集群上。
在创建备份的集群上，表的备份包含创建备份时表中存在的所有数据。备份绝不会大于创建备份时源表的大小。
Bigtable 备份是增量备份。备份所占用的存储空间量取决于表的大小，以及它将未更改的数据与原始表或同一表的其他备份共享的程度。因此，备份的大小取决于数据与上次备份时的差异大小。
您最多可以为每个集群的每个表创建 150 个备份。
可以删除具有备份的表。为保护备份，您不能删除包含备份的集群，也不能删除任何集群中具有一个或多个备份的实例。
从备份恢复到新表后，备份仍然存在。当不再需要它时，您可以将其删除，也可以让其过期。备份存储空间不计入项目的节点存储空间限制。
备份中的数据会被加密。
保留
您可以为备份指定最长 90 天的保留期限。如果您是创建备份的副本，则该副本的最长保留期限为创建副本后的 30 天。
对于启用了自动备份的表，默认保留期限为 3 天。备份的保留期限最长可修改为自备份创建之时起 90 天。
恢复后存储
通过备份恢复的新表的存储费用与其他所有表相同。
通过备份恢复的表可能不会占用与原始表相同的存储空间，并且在恢复后可能会减小。大小差异取决于源集群和目标集群上压缩发生的时间。
由于压缩是滚动执行的，因此压缩操作可能会在表创建后立即进行。但是，压缩最长可能在一周后才进行。
费用
使用备份时，需支付标准网络费用。您无需为备份操作（包括创建备份、复制备份或从备份恢复）付费。
存储费用
如要存储备份或备份的副本，您需要按照包含备份或备份副本的集群所在的区域适用的标准备份存储费率付费。
备份是表的完整逻辑副本。Bigtable 会在后台优化备份存储空间利用率。这种优化意味着备份是增量备份，它会尽可能与原始表或表的其他备份共享物理存储空间。由于 Bigtable 内置了存储优化功能，存储备份或备份副本的费用有时可能会低于表备份的完整实体副本费用。
在启用了自动备份的副本实例中，存储费用可能会更高，因为每个集群每天都会创建备份。
备份复制费用
若在与源备份不同的区域中创建备份的副本，则在将数据复制到目标集群时，需要支付标准网络费用。若在与源备份相同的区域中创建副本，则无需支付网络流量费用。
恢复费用
从备份恢复新表时，您需要支付复制操作的网络费用。如果新表位于使用复制功能的实例中，则您需要为要复制到实例中所有集群的数据支付一次性复制费用。
如果您要恢复到与创建备份的实例不同的实例，并且备份的实例和目标实例在同一区域中没有至少一个集群，则您需要按照标准网络费率，为将数据初始复制到目标集群产生的流量支付费用。
CMEK
在受客户管理的加密密钥 (CMEK) 保护的集群中创建备份时，备份在获取集群的 CMEK 密钥时将固定到密钥的主版本。创建备份后，即使 KMS 密钥已轮替，其密钥和密钥版本也无法修改。
从备份进行恢复时，必须启用备份固定到的密钥版本才能成功执行备份解密过程。对于目标实例中的每个集群，使用 CMEK 密钥的最新主版本来保护新表。如果要从受 CMEK 保护的备份恢复到其他实例，则目标实例也必须受 CMEK 保护，但不需要与源实例具有相同的 CMEK 配置。
复制注意事项
本部分介绍在使用复制的实例中备份和恢复表时要了解的其他概念。
复制和备份
在复制实例中手动备份表时，您可以选择要在其中创建和存储备份的集群。对于启用了自动备份的表，系统会对实例中的每个集群进行每日备份。
无需停止向包含备份的集群写入数据，但您应该了解集群的复制写入的处理方式。
备份是在创建备份时，存储备份的集群上表的状态副本。尚未从实例中的另一个集群复制的表数据不会包含在备份中。
每个备份都有开始时间和结束时间。在备份操作之前不久或期间发送到集群且写入可能不会包括在备份中。导致这种不确定性的因素有两个：
- 写入可能会发送到表中已复制了备份的部分。
- 对其他集群的写入可能尚未复制到包含备份的集群中。
换句话说，一些时间戳早于备份时间的写入可能不会包括在备份中。启用自动备份后创建的备份也是如此。实例的备份并非彼此的完全副本，因为备份时间可能因集群而异。
如果您的业务要求不可接受的这种不一致情况，您可以在写入请求中使用一致性令牌，以确保备份中包含所有复制的写入。
复制和恢复
将备份恢复到新表时，在目标集群上完成恢复操作后，与实例中其他集群之间的复制将立即开始。
性能
创建备份时，请遵循以下最佳实践以确保保持最佳性能。
备份性能
创建备份通常不到一分钟，但最多可能需要一个小时。在正常情况下，备份创建不会影响传送性能。
为实现最佳性能，创建单个表备份的频率不能超过每 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 保护。