本页面介绍了您在通过备份恢复实例或执行时间点恢复 (PITR) 之前要查看的信息。
恢复期间会发生什么？
恢复实例时，主实例中的以下数据将恢复到新实例：
- 数据库
- 用户
恢复操作会导致实例重启。
时间点恢复 (PITR)
借助时间点恢复 (PITR)，您可以将实例恢复到特定的时间点。例如，如果错误导致数据丢失，您可以将数据库恢复到错误发生前的状态。
PITR 会始终创建一个新实例；您无法对现有实例执行 PITR。新实例会继承源实例的设置，工作原理类似于克隆创建。
但是，如果新实例要继承这些设置，则实例的状态必须为 RUNNABLE。
Cloud SQL 对 PITR 使用事务日志。如果您为实例启用 PITR，然后从备份恢复该实例，Cloud SQL 会从恢复的实例中删除可让您使用 PITR 的事务日志。
如需确保实例的日志存储在 Cloud Storage 中（而不是存储在磁盘上），请完成以下操作：
- 检查实例的网络架构。如果实例在旧网络架构上运行，请将实例升级到新网络架构。
- 如果磁盘上的日志的大小导致实例出现性能问题，请先停用 PITR，然后再重新启用。
如需了解执行 PITR 的分步说明，请参阅使用时间点恢复 (PITR)。
关于执行恢复操作的一般提示
在使用备份恢复实例时，无论是恢复到相同实例还是恢复到不同实例，都应牢记以下要点：
- 恢复操作会覆盖目标实例上的所有数据。
- 在恢复操作过程中，目标实例不可用于连接，现有连接也会断开。
- 如果您使用读取副本恢复到一个实例，则必须删除所有副本，并在恢复操作完成之后重新创建它们。
- 恢复操作会重启实例。
如需了解执行恢复操作的分步说明，请参阅：
恢复到不同实例的提示和要求
将备份恢复到不同实例时，请牢记以下限制和最佳做法：
目标实例的数据库版本必须与用于获取备份的实例相同。
Cloud SQL 始终将目标实例的存储容量设置为已配置磁盘和备份磁盘的大小最大值。备份磁盘是进行备份时的磁盘大小。
目标实例的存储容量必须至少与所备份实例的容量一样大。目标实例所占用的存储量无关紧要。您可以在控制台的 Cloud SQL 实例页面查看实例的存储容量。 无论您是否执行单个数据库的 PITR，此要求都适用。
目标实例必须处于
RUNNABLE状态。与最初获取备份的实例相比目标实例可以具有不同的内核数量或内存量。
目标实例可以与来源实例位于不同区域。
在服务中断期间，您仍然可以检索特定项目中的备份列表。请参阅在服务中断期间查看备份。
恢复速率限制
每个项目每个区域每个实例每 30 分钟最多允许执行三项恢复操作。如果恢复操作失败，则不会计入此配额。如果达到限制，操作将失败并显示错误消息，指示何时可以再次运行该操作。
我们来看看 Cloud SQL 如何对恢复执行速率限制。
Cloud SQL 使用存储桶中的令牌来确定任一时段内可以执行多少次恢复操作。对于每个备份，每个目标项目和目标区域都有一个存储桶。来自同一项目的目标实例共用一个存储桶（如果它们位于同一区域）。每个存储桶中最多有三个令牌可用于恢复操作。每隔 10 分钟，系统就会向存储桶添加一个新令牌。如果存储桶已满，则令牌会溢出。
每次您发出恢复操作时，系统都会从存储桶授予令牌。如果操作成功，则系统会从存储桶中移除令牌。如果失败，令牌会返回到存储桶。下图展示了其工作原理：
例如，在下图中，Backup1、Backup2 和 Backup3 是来自同一来源实例的备份。
- 每个备份（Backup1、Backup2 和 Backup3）都有自己的用于恢复操作的令牌存储桶，这些令牌存储桶针对的是区域 A 的项目 1 中的不同实例（Bucket11A、Bucket21A 和 Bucket31A）。由于每个备份都有自己的存储桶，因此您可以每 30 分钟将每个备份恢复到同一实例三次。
- 每个备份都有一个针对不同项目和不同区域的存储桶。例如，如果一个区域中有五个项目，则该区域中的备份有五个存储桶，每个项目一个。在上图中，我们在区域 A 中有两个项目：项目 1 和项目 n。
- Backup1 在区域 A 中有两个用于恢复操作的令牌存储桶。一个存储桶针对项目 1 (Bucket11A)，另一个存储桶针对项目 n (Bucket1nA)。
- 同样，Backup3 在区域 A 中有两个用于恢复操作的存储桶。一个针对项目 1 (Bucket31A)，另一个针对项目 n (Bucket3nA)。
- Backup3 在区域 B 中有一个针对 Project1 的存储桶，因为同一目标项目和同一目标区域中的所有实例都共用一个存储桶。